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Foreword 



This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



This Technical Specification (TS) describes the Service Principles for PLMNs specified by 3GPP. Principles and 
requirements for interworking with WLAN are covered in TS22.234 [35]. 

3GPP specifications provide integrated personal communications services. The system will support different 
applications ranging from narrow-band to wide-band communications capability with integrated personal and terminal 
mobility to meet the user and service requirements of the 2r' century. 

3GPP specifications allow the realisation of a new generation of mobile communications technology for a world in 
which personal communications services should allow person-to-person calling, independent of location, the terminal 
used, the means of transmission (wired or wireless) and the choice of technology. Personal communication services 
should be based on a combination of fixed and wireless/mobile services to form a seamless end-to-end service for the 
user. 

3GPP specifications should be in compliance with the following objectives: 

a) to provide a single integrated system in which the user can access services in an easy to use and uniform way in 
all environments; 

b) to allow differentiation between service offerings of various serving networks and home environments; 

c) to provide a wide range of telecommunications services including those provided by fixed networks and 
requiring user bit rates of up to 100 Mbits/s as well as services special to mobile communications. These services 
should be supported in residential, public and office environments and in areas of diverse population densities. 
These services are provided with a quality comparable with that provided by fixed networks such as ISDN and 
fixed broadband Internet access; 

d) to provide services via hand held, portable, vehicular mounted, movable and fixed terminals (including those 
which normally operate connected to fixed networks), in all environments (in different service environments - 
residential, private domestic and different radio environments) provided that the terminal has the necessary 
capabilities; 

e) to provide support of roaming users by enabling users to access services provided by their home environment in 
the same way even when roaming. 

f) to provide audio, data, video and particularly multimedia services; 

g) to provide for the flexible introduction of telecommunication services; 

h) to provide within the residential environment the capability to enable a pedestrian user to access all services 
normally provided by fixed networks; 

i) to provide within the office environment the capability to enable a pedestrian user to access all services normally 
provided by PBXs and LANs; 

j) to provide a substitute for fixed networks in areas of diverse population densities, under conditions approved by 
the appropriate national or regional regulatory authority. 

k) to provide support for interfaces which allow the use of terminals normally connected to fixed networks. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 
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[43] GSMA PRD IR.34: "Inter-Service Provider IP Backbone GuideUnes" 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

eCall: A manually or automatically initiated emergency call,(TS12) from a vehicle, supplemented with a minimum set 
of emergency related data (MSD), as defined under the EU Commission"s eSafety initiative. 

IMS Centralized Services: The provision of communication services wherein services and service control are based on 
IMS mechanisms and enablers, and support is provided for a diversity of access networks (including CS domain and IP 
based, wireless and wireline), and for service continuity between access networks. 

MSD: The Minimum Set of Data [46] forming the data component of an eCall sent from a vehicle to a Public Safety 
Answering Point or other designated emergency call centre. The MSD has a maximum size of 140 bytes and includes, 
for example, vehicle identity, location information and time-stamp. 
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Further definitions are given in 3GPP TR 21.905 [29]. 

3.2 Abbreviations 

For the purposes of this TS, the following abbreviations apply: 

IVS In Vehicle System (eCall terminal and associated sub-systems in vehicle) 

ME Mobile Equipment 

PC Personal Computer 

Further abbreviations are given in 3GPP TR 21.905 [29]. 



4 General 

4.1 Aims of 3GPP specifications 

It shall be capable of delivering audio, text, video and graphics direct to people and provide them with access to the next 
generation of information based services. It moves mobile and personal communications forward from existing systems, 
delivering mass market low-cost digital telecommunication and IP-based multimedia services. 

The aims are: 

to enable users to access a wide range of telecommunications services, including many that are today undefined 
as well as multi-media and high data rates. 

to facilitate the provision of a high quality of service (particularly speech quality) similar to that provided by 
fixed networks; 

to facilitate the provision of small, easy to use, low cost terminals with long talk time and long standby 
operation; 

to provide an efficient means of using network resources (particularly radio spectrum). 

4.2 Standardisation of Service Capabilities 

Existing systems have traditionally standardised the complete sets of teleservices, applications and supplementary 
services which they provide. As a consequence, substantial efforts are often required to introduce new services or 
simply to modify the existing one (customisation). This makes it more difficult for operators to differentiate their 
services. At the same time however, this may reduce the complexity of providing a service across different operators" 
networks. 

3GPP shall therefore preferentially standardise service capabilities. In circumstances where the service is meant to be 
used across different operators" networks, hence a common specification set is of paramount importance, the service 
should be standardised to a level of detail sufficient to ensure interoperability and interworking across different 
operators" networks. Service capabilities consist of bearers defined by QoS parameters and the mechanisms needed to 
realise services. These mechanisms include the functionality provided by various network elements, the communication 
between them and the storage of associated data. This TS provides a conceptual description of a service architecture and 
architecture requirements which aim to provide service capabilities. It is intended that these standardised capabilities 
should provide a defined platform which will enable the support of speech, video, multi-media, messaging, data, 
teleservices, user applications and supplementary services and enable the market for services to be determined by users 
and home environments. 

4.2.1 Provision of service capabilities in shared networks 

The provision of services and service capabilities that is possible to offer in a network shall not be restricted by the 
existence of the network sharing It shall be possible for a core network operator to differentiate its service offering from 
other core network operators within the shared network. 
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It shall be possible to control the access to service capabilities offered by a shared network according to the core 
network operator the user is subscribed to. 

4.3 Efficient Use of Network Resources 

4.3.1 Network Traffic Patterns 

Service capabilities shall take account of the discontinuous and asymmetric nature of most teleservices, multimedia 
services and user applications in order to make efficient use of network resources (particularly radio resources). 

4.3.2 IVIass Simultaneous Registration 

When a large number of subscribers enter in a registration area in which they have not registered, the core and radio 
access network shall be able to provide a capability to optimize the mass simultaneous registration traffic at a given 
instance of time. The core and radio access network shall be able to keep providing the service (e.g. mobile originated 
and mobile terminated services) without interruption for those subscribers who are originally in the cell which receive 
the mass simultaneous registration traffic. 

4.3.3 Radio Interface 

Service capabilities shall be provided in a wide range of radio operating environments (where a radio environment is 
characterised in terms of propagation environment, mobile equipment relative speeds and traffic characteristics). 
Although 3GPP aims to minimise the number of radio interfaces and to maximise commonality between them, it may 
utilise several radio interfaces, each optimised for different environments. Each radio interface may provide differing 
service capabilities. 3GPP specifications include UTRA(N) radio interface supporting two modes (TDD and FDD), an 
Evolved UTRA(N) radio interface and GERAN radio interface. Additionally, it may be possible to connect to the 3GPP 
system using radio interfaces and fixed access technologies specified outside of 3GPP. 

3GPP specifications shall provide a mechanism which will enable a piece of user equipment (UE) to adapt to different 
radio interfaces as necessary and to determine the service capabilities available. The specifications shall also provide a 
mechanism which will enable a UE to select radio interfaces capable of providing appropriate service capabilities and 
support mobility between multiple radio interfaces. 

4.3.4 Real-time Resource Usage 

To enable network operators to render services efficiently, dimension their networks and set tariffs that more accurately 
reflect radio resource usage, real time information on resource usage is needed. When requested, it shall be possible for 
the serving cell type (e.g. RAT), cell ID / UTRAN Service Area Identity and cell / Service Area capability usage (e.g. 
HSDPA, E-DCH) information to be made available to the core network. Cell / Service Area capability usage 
information may include, for example, user(s) identity, start and finish time of data transfer, up-link and down-link data 
rates, volumes of data and other statistical information. 

4.3.5 Selected IP Traffic Offload (SIPTO) for PS Domain only 

4.3.5.1 Common Requirements for SIPTO in the Mobile Operator Network and 

SIPTO at the Local Network 

It shall be possible to offload selected traffic (e.g. internet) associated with a particular APN close to the UE's point of 
attachment to the access network. 

The following requirements apply to Selected IP Traffic Offload: 

The mobile operator may enable/disable Selected IP Traffic Offload on a per UE per APN basis (e.g. based on 
tariff, subscription type etc.). 

It shall be possible for IP traffic of a UE associated with a particular APN to be offloaded while IP traffic of that 
same UE associated with other APN(s) is not offloaded. 
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It shall be possible to perform Selected IP Traffic Offload per APN for pre-Release 10 UEs. 

Offloading selected IP traffic for a UE shall not affect services running in parallel for the same UE. 

The mobile operator shall be able to collect signalling performance measurements (e.g. session 
connection/disconnection, etc) related to Selected IP Traffic Offload for each user. 

Selected IP Traffic Offload shall not compromise the security of the mobile operator's network. 

Selected IP Traffic Offload may support mobility during the following mobility events: 

mobility between the macro network and H(e)NBs; and 

mobility between H(e)NBs. 

Any interruption to the data flow during both these mobility events shall be minimised. 

It shall be possible for the HPLMN to provide the VPLMN with the following information for a particular user: 

An indication of whether the user"s IP traffic associated with a particular APN is permitted to be 
subjected to Selected IP Traffic Offload in the visited network; 

The APN(s) for which Selected IP Traffic Offload is permitted. 

Requirements specific to SIPTO at the local residential/enterprise IP network can be found in section 5.9 in [48]. 

4.3.5.2 Requirements for SIPTO in the IVIobile Operator Network 

The following requirements apply to Selected IP Traffic Offload in the mobile operator network: 

The mobile operator shall be able to enable/disable Selected IP Traffic Offload for certain parts of the network. 

Selected IP Traffic Offload shall not compromise integrity and confidentiality of offloaded traffic. 

The mobile operator shall be able to collect statistics for the offloaded traffic for each user. 

The network shall be able to perform Selected IP Traffic Offload for user"s IP traffic associated with a particular 
APN without any user interaction based on mobile operator policies. 

Selected IP Traffic Offload shall support mobility within the macro network, Any interruption to the data flow 
during mobility within the macro network shall be minimised. 

4.4 Compatibility with Global Standards 

3GPP specifications aim to be compatible with IMT-2000 and to provide global terminal mobility (roaming), enabling 
the user to take his/her terminal to different regions of the world and to be provided with services. It is probable that 
different regions of the world will adopt different radio interface technologies. IMT-2000, as a global standard, should 
therefore enable a IMT-2000 terminal to determine the radio interface technology and the radio interface standard used 
in a region. Global terminal roaming also requires the global standardisation of service capabilities. As far as possible 
the method of indication of the radio interface standard and available service capabilities shall be aligned with IMT- 
2000. 

3GPP specifications shall enable users to access the services provided by their home environment in the same way via 
any serving network provided the necessary service capabilities are available in the serving network. 

The 3GPP specifications will be available for the partner organisations to adopt as their regional standards. For example 
in Europe, ETSI may adopt them as standards for both GSM and UMTS. 
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4.5 Void 

4.6 Functionality of Serving Network and Home Environment 

The following functionality shall be the responsibility of the home environment: 
User Authentication. 

- SIM/USIM Issue. 

- Bilhng. 

User Profile/VHE Management. 

The following functionality shall be the responsibility of the serving network: 

Radio or other means of access. 

Transport and signalling. 

The following functionality may be the responsibility of either the serving network, the home environment or an 
appropriate combination of both 

Service Control. 

QoS negotiation. 

Mobility management, including roaming. 

Automatic establishment of roaming agreements. 

4.7 PLIVIN Architecture 

The network is logically divided into a radio access network and a core network, connected via an open interface. From 
a functional point of view the core network is divided into a Packet Switched CN Domain, IP Multimedia (IM) CN 
subsystem [27] and a Circuit Switched CN Domain. IM CN subsystem utilises PS CN domain bearer services. 

CS CN domain supports bearer independent transport. There is no difference in service offering or UE functionality due 
to different transport. 

A PS only 3GPP core network is possible as defined within the specification for the Evolved Packet System (EPS) [42]. 

For further information see 3GPP TS 23.221 [20]. 

4.8 Interworking Between PLIVIN and Wireless LANs 

Aspects related to interworking between PLMN and WLAN are captured in TS 22.234 [35]. 

4.9 Network Sharing 

Network sharing shall be transparent to the user. 

The specifications shall support both the sharing of: 

(i) radio access network only; 

(ii) radio access network and core network entities connected to radio access network 

NOTE: In a normal deployment scenario only one or the other option will be implemented. 

It shall be possible to support different mobility management rules, service capabilities and access rights as a function 
of the home PLMN of the subscribers. 
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4.10 The Evolved Packet System 



Evolved Packet System is an evolution of the 3G UMTS characterized by higher-data-rate, lower-latency, packet- 
optimized system that supports multiple RATs. The Evolved Packet System comprises the Evolved Packet Core 
together with the evolved radio access network (E-UTRA and E-UTRAN).The service requirements for the Evolved 
Packet System are specified in TS22.278 [42]. 

4.1 1 User Data Convergence 
4.11.1 Introduction 

The UDC concept [45] supports a layered architecture, separating the data from the application logic in the 3GPP 
system, so that user data is stored in a logically unique repository allowing access from core and service layer entities, 
named application front-ends. And such unique repository shall be possible to be shared among different PLMNs that 
have trusted relationships. 

Network elements and functionalities should be designed to access profile data remotely and without storing them 
permanently locally, i.e. the front-ends shall work in a subscriber dataless configuration. 

In some cases, services may depend on user data scattered over UDC and other network elements. UDC may support 
the ability to access necessary network elements to fetch user data on behalf of these services, while minimizing 
impacts on existing Network Elements in which the data is located. 

Applications can subscribe to specific events which will likely occur on specific user data, and those should be notified 
when those events do appear. The events can be changes on existing user data, addition of user data, and so on. 

Third party applications and non trusted network elements should only be able to access the user data after proper 
authentication and authorization taking into account security and privacy requirements, i.e. it should be possible to 
present different views on the data to the parties which require access, dependent on the authorization. UDC concept is 
backwards compatible with 3GPP systems, i.e. it does not have an impact on traffic mechanisms, reference points and 
protocols of existing network elements. 

The UDC concept preserves user authentication and authorization of services across domains, ensuring secured users" 
access to network. 



4.1 1 .2 Management of user data 



Due to the logical centralization of user data, it is necessary for UDC to support the provisioning of the user data, that 
is, user data manipulation like creation, deletion, reading, modification and other operations. Provisioning shall be 
possible via an external system, self care or dynamically via applications offering e.g. user service configuration 
facilities. 

Operations carried out in the framework of UDC shall support the ACID (Atomicity, Consistency, Isolation, and 
Durability) characteristics. 



4.11.3 User Data Modelling 



User Data Modelling refers to the different models that apply to user data convergence: Information Models and Data 
Models. 

An Information Model denotes an abstract, formal representation of entity types, including their properties and 
relationships, the operations (e.g. read, write...) that can be performed on them, and related rules and constraints. In the 
information model, entities might have network topology relationship with each other. 

In order to accommodate multiple applications and services, existing and new ones, a common baseline information 
model shall be developed and shall, at minimum, clearly distinguish a number of concepts as entity types: 

Subscriber with relation to several users (e.g. a company and its employees), 

A user attached to different subscriptions (e.g. for a private and a professional service usage) 

A user using multiple devices (e.g. mobiles or fixed) 
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Grouping of users to certain categories 

A particular user as member of a certain group 

Service providers" services provided by network operators 

Enterprise services provided by network operators 

The baseline information model shall be future proof. It shall not be tied to any specific implementation of the data base 
or its interfaces. It shall provide flexibility (in its data structure and content), extensibility and multi-application 
approach. 

By extensible, it shall be understood that new applications and/or new service profiles can be added by the operator, if 
necessary. The flexibility shall permit new data for existing applications to be introduced, or modified. 



Data Models are practical implementations of the information model, e.g. Tree-like modelling. The common 
information model shall allow deriving one or more data models. A reference data model shall be standardized for the 
message exchange over Ud interface [50], in order to enable multivendor interoperability. 

Each application shall only interface the UDC for the data it is dealing with, and not be impacted by other data that 
UDC stores for other applications. It corresponds to the concept of a data view specific to a given application. 

An application can allow access by other applications to data for which it is responsible. This can be done under certain 
constraint customized by operators. 

Access to the UDC data shall be independent of the structure of the data models, i.e. the changes in the data models 
shall not affect the interface. 

5 Evolution 

5.1 Support of 2G services 

The 3GPP specifications shall be capable of supporting existing 2G services in a manner which is transparent to the 
users of these services. 

5.2 Provision and evolution of services 

Since a phased approach has been adopted, the same general service principles shall apply to each phase. Support of 
services from an end user perspective is understood to be an important driver for established mobile users to stay with 
their existing operator while taking the new services into use. It is therefore important to enable operators to offer 
continued support of legacy services in future releases. Previous release services shall as a principle also be supported in 
the following releases. 

Networks shall be capable of providing a specified core set of capabilities. 

The core set of capabilities should permit home environment to offer a range of distinctive services including those 
which cannot be implemented on systems based on previous release specifications. 

It shall be possible for the home environment to develop services with full roaming capability. 

The radio interface should not unnecessarily restrict the development of new services (within physical limitations). 

The standard shall provide a mechanism which allows a terminal to be easily upgraded so that it can access new 
services which are within the physical limitations of the terminal. 
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Classification of services 



In the CS CN domain, the basic services are divided into circuit teleservices (3GPP TS 22.003 [14]) and bearer services 
(3GPP TS 22.002 [21]) and they can utilise standardised supplementary services (3GPP TS 22.004 [5]). 

The PS CN Domain provides IP bearer services. SMS, USSD and UUS can also be considered as bearer services for 
some applications. 

IP multimedia services are the IP based session related services, including voice communications. IP multimedia 
sessions use IP bearer services provided by the PS CN Domain. 

Value added non-call related services include a large variety of different operator specific services/applications. They 
are usually not specified by 3GPP. The services can be based on fully proprietary protocols or standardised protocols 
outside 3GPP. 

In order to create or modify the above services (both call and non-call related services) operators may utilise toolkits 
standardised by 3GPP (such as CAMEL or LCS) or external solutions (e.g. Internet mechanisms). Pre-paid is an 
example of an application created with toolkits that may apply to all of the above services categories. 
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Figure 1 : Service classification 



Principles for new service capabilities 



7.1 



General 



3GPP specifications shall enable the user of a single terminal to establish and maintain several connections 
simultaneously. It shall efficiently cater for applications which have variable requirements relating to specific QoS 
parameters (e.g. throughput) whilst meeting other QoS targets. It shall also cater for applications which are able to take 
adapt to a range of variations in QoS. 
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7.2 Multimedia 

3GPP specifications shall support development of multimedia services and provide the necessary capabilities. 

Multimedia services combine two or more media components (e.g. voice, audio, data, video, pictures) within one call. 
A multimedia service may involve several parties and connections (different parties may provide different media 
components) and therefore flexibility is required in order to add and delete both resources and parties. 

Multimedia services are typically classified as interactive or distribution services. 

Interactive services are typically subdivided into conversational, messaging and retrieval services: 

Conversational services are real time (no store and forward), usually bi-directional where low end to end delays (< 100 
ms) and a high degree of synchronisation between media components (implying low delay variation) are required. 
Video telephony and video conferencing are typical conversational services." 

Messaging services offer user to user communication via store and forward units (mailbox or message handling 
devices). Messaging services might typically provide combined voice and text, audio and high-resolution images. 

Retrieval services enable a user to retrieve information stored in one or many information centres. The start at which an 
information sequence is sent by an information centre to the user is under control of the user. Each information centre 
accessed may provide a different media component, e.g. high resolution images, audio and general archival information. 

Distribution services are typically subdivided into those providing user presentation control and those without user 
presentation control. 

Distribution services without user control are broadcast services where information is supplied by a central source and 
where the user can access the flow of information without any ability to control the start or order of presentation e.g. 
television or audio broadcast services. 

Distribution services with user control are broadcast services where information is broadcast as a repetitive sequence 
and the ability to access sequence numbering allocated to frames of information enables the user (or the user"s terminal) 
to control the start and order of presentation of information. 

7.2.1 Circuit Switclned (CS) multimedia calls 

CS multimedia call is a Bearer Service which utilises Synchronous Transparent Data service. The following basic 
requirements shall be supported for CS multimedia calls [24]: 

CS multimedia call shall be based on a 3GPP specific subset of H.324M. 

All call scenarios shall be supported, i.e. Mobile Originating and Mobile Terminating call against Mobile, ISDN 
and PSTN call party. 

Single and multiple numbering schemes shall be supported. 

Fallback to speech (TS 1 1 [14]) shall be supported from 3. IkHz Ext. PLMN multimedia bearer, i.e. if setup of 
the multimedia call fails the call will be set up as a speech call. 

Service change and fallback shall be supported for UDI/RDI multimedia bearer and speech, to allow fallback to 
a less preferred service if the preferred service is unsupported, and to change the service between speech and 
multimedia during the call. 

In the case where a CS multimedia call includes speech (e.g. video call) then the following requirements apply: 

A user shall be able to change between a speech and CS multimedia call, when desired. 

When the CS multimedia call is no longer supported, for example due to degraded coverage conditions 
(including UTRAN to GERAN only transitions), service change shall occur automatically from a CS 
multimedia call to speech. 

When a CS multimedia call can be supported, for example due to improved coverage conditions (including 
GERAN only to UTRAN or UTRAN/GERAN transitions), service change back to the CS multimedia call 
may be initiated by the network. 
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Other services than CS multimedia call may exist which utilise the Synchronous Transparent Data service. 
Service transition to/from speech described for CS multimedia call in this clause shall only apply to CS 
multimedia call and not Synchronous Transparent Data services in general. 

Different bitrates as specified at 3GPP TS 22.002 [21] shall be supported. 

Supplementary services apply to multimedia calls as for Synchronous Transparent Data service according to 

3GPPTS22.004[5]. 

When accepting a multimedia call, the user shall be able to request a service change to speech before the call is 
answered, such that the multimedia path is never actually connected through to the user"s phone. 

The user shall be able to deny a service change to multimedia during the call. 

7.2.2 IP multimedia (IM) sessions 

IP multimedia services are not the evolution of the circuit switched services but represent a new category of services, 
mobile terminals, services capabilities, and user expectations. Any new multimedia service, which may have a similar 
name or functionality to a comparable standardised service, does not necessarily have to have the same look and feel 
from the user's perspective of the standardised service. Voice communications (IP telephony) is one example of real- 
time service that would be provided as an IP multimedia application. 

The following basic requirements are be supported for IP multimedia [27]: 

IP multimedia session control shall be based on SIP [28]. 

All session scenarios shall be supported; i.e. Mobile Originating and Mobile Terminating sessions against 
Internet/Intranet, CS or IM Mobile, ISDN, PSTN call party. 

MSISDN and SIP URL numbering and addressing schemes shall be supported. 

IP multimedia applications shall as a principle, not be standardised, allowing service provider specific variations. 

7.2.3 Multimedia Messaging Service (MMS) 

The following basic requirements are be supported for MMS: 

Store-and-forward multimedia messaging service with mobile and non-mobile users [25]. 

MMS shall be capable of supporting integration of different types of messaging (e.g. fax, SMS, Multimedia, 
voicemail, e-mail etc.) in a consistent manner. 

Streamed and batch delivery for both message download from the network to the terminal, and messages upload 
from the terminal to the network. 

7.2.4 Text Conversation 

Global Text Telephony ( GTT ) is a feature that enables real-time text conversation [26]. 

GTT enables real time, character by character, text conversation to be included in any conversational service. 
Circuit Switched as well as IP based. 

It is possible to use the text component in a session together with other media components, especially video and 
voice. 

Interworking with existing text telephony in PSTN as well as emerging forms of standardised text conversation 
in all networks is within the scope of this feature. 

The text media component can be included initially in the session, or added at any stage during the session. 

The text component is intended for human input and reading, and therefore supports human capabilities in text 
input speed. The character set support is suitable for the languages the users communicate in. 
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GTT specifies limited interoperation with Multimedia Messaging Services including a possibility to divert to 
messaging in case of call failure and sharing user interface equipment and external UE interfaces. 

7.2.5 Packet Switched Streaming Service 

The following basic requirements are to be supported for streaming : 

The streaming service uses a client / server model which is transparent to the PLMN. The client controls the 
initiation and execution of the service. 

The streaming service [30] shall use existing standards (codecs and protocols [31]) where these are available. 

- The streaming service utilises the PS Domain with the QoS requirements as specified in 3GPP TS 22.105 [1]. 

7.3 Service Management Requirements 

3GPP specifications shall include standardised protocols enabling service management. It shall enable control, creation 
and subscription of service capabilities and services, and the management of user profiles. 

7.4 Automatic Device Detection 

The home environment should be automatically notified when a user, identified by a SIM/USIM, has changed ME and 
should be informed of the identity of the new ME. This should be applicable to any ME. It should also be possible to 
achieve Automatic Device Detection for users using any SIM/USIM. 

Note: The purpose of this is to enable an automatic configuration of terminals by the operator for specific 
applications/services if so needed. The procedure for such an automatic configuration need not to be 
standardized by 3GPP. 

The notification that a user has changed ME shall be given as early as possible. 



8 Service architecture 

In order to provide standardisation of service capabilities a service architecture shown by Figure 2 is envisaged 
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Figure 2: Service Architecture 
Figure 2: Service Architecture 

A number of bearers shall be provided that can differ in flexibility and offer different capabilities. Bearers may be 
characterised by parameters such as "throughput", "delay tolerance", "maximum bit error rate", "symmetry" etc. These 
bearers enable information to be transferred appropriate to the provision of teleservices, multimedia services and end 
user applications generally, via subnetworks which typically provide different specified qualities of service. 

The assignment and release of bearers is provided by the bearer control function. Provision should be made for several 
bearers to be associated with a call and for bearers to be added to a call and/or to be released from a call following call 
establishment. The bearers should be independent of radio environments, radio interface technology and fixed wire 
transmission systems. 

Adaptation/Interworking functions are required in order to take account of the differences between the bearers used for 
the provision of a teleservice/multimedia service/application in the fixed network and the bearers. 
Adaptation/Interworking functions are required which take account of the discontinuous and/or asymmetrical nature of 
most teleservices/multimedia services/applications. 

The service platform shall provide interfaces (to serving networks and home environments) appropriate to the support, 
creation and control of supplementary services, teleservices, multimedia services and user applications. The service 
platform will also provide interfaces enabling subscribers to control supplementary services, teleservices, multimedia 
services and user applications. 

Supplementary service provision and control will be independent of radio operating environment, radio interface 
technology and fixed wire transmission systems. 

As far as possible, the service platform is required to enable new supplementary services, teleservices, multimedia 
services and/or end user applications to be supported at minimum cost, with minimum disruption of service and within 
the shortest possible time. 



Quality of Service (QoS) 



The Quality of Service (QoS) parameters should be identified together with appropriate parameter values which set 
targets to be reached when designing 3GPP specifications, and which also will serve as guidelines for network design 
and service provision. 

The QoS for call set-up time, as an example, can be defined in terms of a mean value and as a percentage of cases 
which should not exceed a certain time limit. Further information can be found in 3GPP TS 22.105[1]. 
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The performance requirements for the All-IP Network can be found in 3GPP TS 22.278[42]. 

For UE initiated QoS control OMA device management shall be the primary method for provisioning QoS parameters. 



10 Emergency Calls 
10.1 General requirements 

It shall be possible to establish an emergency speech call or GTT [26] call (subject to national requirements). The term 
"Emergency call" henceforth refers to speech calls, and GTT Emergency calls if applicable. The term "other media" 
henceforth refers to media other than speech and GTT. Support of other media types during an emergency call when the 
IM CN subsystem is used is referred to as IMS Multimedia Emergency Session' (MES) and is specified in subclause 
10.4.2. Emergency calls will be routed to the emergency services in accordance with national regulations for where the 
subscriber is located. This may be based upon one or more default emergency call numbers stored in the ME. It shall be 
allowed to establish an emergency call without the need to dial a dedicated number to avoid the mis-connection in 
roaming case, such as menu, by use of a 'red button', or a linkage to a car air bag control. Emergency calls shall be 
supported by the UE without a SIM/USIM/ISIM being present. No other type than emergency calls shall be accepted 
without a SIM/USIM/ISIM. 

Emergency calls shall be supported by UEs that are subject to service restrictions, e.g. for UEs camping on a cell in a 
forbidden PLMN or in a forbidden LA (see 3GPP TS 22.01 1 [11]), or on a CSG cell without the subscriber being a 
member of that CSG (see 3GPP TS 22.220 [48]). Such emergency calls shall be accepted by the network if required by 
local regulation. 

The Emergency service is required only if the UE supports voice. 

NOTE 1 : It will be left to the national authorities to decide whether the network accepts emergency calls without 
the SIM/USIM/ISIM. 

It shall be possible to initiate emergency calls to different emergency call centres, depending on the type of emergency. 
The following types of emergency calls shall be possible: 

Police 

Ambulance 

Fire Brigade 

Marine Guard 

Mountain Rescue 

Manually Initiated eCall (MleC) 

Automatically Initiated eCall (AleC) 

Spare 

When a SIM/USIM is present, subscriber specific emergency call set-up MMI shall be provided. The Home 
Environment operator shall specify preferred emergency call numbers (e.g. 999 for UK citizens or 110, 118 and 119 for 
Japanese citizens). These emergency call numbers shall be stored in the SIM/USIM and the ME shall read this and use 
any entry of these digits to set up an emergency call. It shall be possible to store more than one instance of this field. 

NOTE 2: Release '98 and earlier SIM cards have the capability to store additional emergency call numbers. 
However in many cases this has not been used. 

It shall be possible to tie any emergency call number to any single emergency call type or to any combination of 
emergency call types. The association between emergency call numbers and emergency call type shall be able to be 
programmed by the Home Environment operator into the SIM/USIM. 

Example: 

19 Police (Albania) 
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100 Police and Fire Brigade (Greek cities) 

100 Ambulance and Fire Brigade (Belgium) 

112 Police and Ambulance (Italy) 

112 General emergency call, all categories (Sweden) 

115 Fire Brigade (Italy) 

144 Ambulance (Austria) 

If the UE does not recognise the emergency call numbers but the serving network recognises the dialled number as an 
emergency call number used in the country, a normal call set up shall take place over the radio interface and after the 
serving network has recognised the emergency number the call shall be routed as an emergency call. 

The user friendly MMI that specifies the type of emergency call directly (e.g. menu) should be supported for use in any 
(i.e. home or visited) PLMN to avoid the mis-connection in roaming case. This shall be allowed both with and without 
SIM/USIM being present. 

When emergency call establishment is initiated, the emergency call type shall be sent by the UE if it is available. 

The serving network may download emergency call numbers to the UE in order to ensure that local emergency call 
numbers are known to the UE. The UE shall regard these emergency numbers as valid in that country only (as 
identified by the MCC) and shall discard them when a new country is entered. 

NOTE 3: The UE can inform the user if the emergency call type for an emergency number received from the 
serving network differs from that configured on the USIM/SIM for the same number. How this is 
implemented is outside the scope of 3GPP and takes into consideration operator policy and regulatory 
requirements. 

If permitted by local regulation, it shall be possible for the user to prevent the sending of his public user identifiers and 
the location information to the PSAP (i.e. emergency response centre). 

NOTE 4: Operator policies (e.g. requirements for support of emergency communications) may over-ride the user 
request for suppression. 

10.1.1 Identification of emergency numbers 

The ME shall identify an emergency number dialled by the end user as a valid emergency number and initiate 
emergency call establishment if it occurs under one or more of the following conditions. If it occurs outside of the 
following conditions, the ME should not initiate emergency call establishment but normal call establishment. 
Emergency number identification takes place before and takes precedence over any other (e.g. supplementary service 
related) number analysis. 

a) 1 12 and 911 shall always be available. These numbers shall be stored on the ME. 

b) Any emergency call number stored on a SIM/USIM when the SIM/USIM is present. 

c) 000, 08, 1 10, 999, 118 and 119 when a SIM/USIM is not present. These numbers shall be stored on the ME. 

d) Additional emergency call numbers that may have been downloaded by the serving network when the SIM/USIM 
is present. 

10.1.2 Domains priority and selection for UE attempts to emergency call 
10.1.2.1 Voice and GTT only 

A UE that is connected to a domain in which it is possible for the UE to make non emergency calls using the particular 
media requested by the user, shall use that domain to attempt an emergency call unless serving network policy (based 
on regulatory requirements and operator needs) requires the UE, including an unauthenticated UE, to attempt the 
emergency call on a specific domain first. 
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If the UE is connected to more than one domain in which it is possible for the UE to make non emergency calls using 
the particular media requested by the user, the UE shall attempt an emergency call on the same domain it would use to 
originate a non-emergency call using the same media unless serving network policy (based on regulatory requirements 
and operator needs) requires the UE, including an unauthenticated UE, to attempt the emergency call on a specific 
domain first. 

In the case where an emergency call attempt by a UE fails, the UE should automatically make a second attempt on the 
other domain if the UE supports it. 

If the user aborts the emergency call setup during the subsequent automatic attempt and immediately tries to set up an 
emergency call again, then the UE shall immediately attempt in the domain in which the user aborted the emergency 
call. 

10.1.2.2 Other media 

The following applies in addition to 10.1.2.1. 

If an emergency call attempt that includes a request for both (i) voice and/or GTT and (ii) other media cannot be 
supported or fails in all connected access types in the PS CN domain, the UE shall attempt the emergency call in the CS 
domain if available and shall only include the request for voice and/or GTT. 

10.1.3 Call-Back Requirements 

Subject to local/regional regulations the network shall support a call-back from a PSAP. 

It shall be possible to supply the user"s Directory Number/MSISDN/SIP URI as the CLI to the PSAP to facilitate call- 
back. The CLI used on call-back shall allow the PSAP to contact the same terminal that originated the emergency call. 

NOTE: There is no specific callback requirement for CS supplementary services. 

A call-back may be attempted for a period of time defined by local regulations after the emergency call release. In case 
of a UE in limited service state, call-back is not required. 

1 0.2 Emergency calls in the CS CN Domain 

A CS CN Domain shall support the emergency call teleservice as defined in 3GPP TS 22.003 [14] (TS12). 

If a UE supports TS 11 (Telephony) [14], then it shall also support TS12(Emergency Calls)[14]. It shall be possible to set 
up emergency calls initiated by an emergency call number. 

1 0.3 Emergency Calls in the PS CN Domain 

Without the IM CN subsystem, emergency calls are not supported in the PS CN domain. 

1 0.4 Emergency calls in the IIVI CN subsystem 
10.4.1 General 

The IM CN subsystem shall support IMS emergency calls. It shall be possible to set up emergency calls initiated by an 
emergency call number. 

If a UE supports IMS Multimedia Telephony service with speech media as specified in TS 22. 173 [40] via an access 
network, then it shall also support IMS emergency calls via that access network. 

Subject to the regulatory requirement, the IM CN subsystem shall be able to unambiguously identify each emergency 
service defined in the national numbering plan for the country in which the UE is located. 

In accordance with national regulations for where the subscriber is located, if the UE does not recognise a dialled 
number as an emergency call number but the IM CN where the subscriber is located does recognise the dialled number 
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as an emergency call number (e.g. a number used in the local emergency numbering plan) then the call shall be routed 
as an emergency call indicating the type of emergency service to the correct PSAP. Subject to operator setting the call 
may be prioritized. 

NOTE 1: The above does not preclude the network rejecting the call and requesting the UE to setup a new 
emergency call to the same emergency service. 

Emergency calls may be initiated using a private numbering plan [49]. 

NOTE 2: There can be an overlap between the private numbering plan of a hosted enterprise and the public 
numbering plan, which makes translation of emergency numbers necessary. 

Emergency calls may be initiated by a service when requested by the user. 

NOTE 3: It is not intended to enable automatic setup of emergency calls. 

NOTE 4: Only speech and GTT-IP [47] media are supported, when required per clause 10.1, for emergency 
services towards a CS PSAP. 

An emergency call shall take precedence over any other services a UE may be engaged in, if required by local 
regulation. 

Emergency calls from an unauthenticated UE (as far as the IM CN is concerned) shall be supported by the IM CN 
subsystem, if required by local regulation. 

Subject to regulatory requirements, when UEs must be authenticated, both the network and the UE shall support the 
same authentication and security methods that are used for non-emergency sessions. 

1 0.4.2 IMS Multimedia Emergency Sessions 
10.4.2.1 General 

For IMS emergency calls towards IP PSAPs, other media types may be supported by the UE and the IMS, subject to 
regulatory requirements. 

The media types that may be supported during an IMS MES include: 

Real time video (simplex, full duplex), synchronized with speech if present; 

Session mode text-based instant messaging; 

File transfer; 

Video clip sharing, picture sharing, audio clip sharing; 

Voice; and 

- GTT. 

NOTE 1: An IMS MES need not contain voice or GTT. 

To avoid interworking issues, a UE and IMS that supports text based instant messaging shall support a common session 
mode text-based instant messaging protocol. 

IMS MES does not include support for legacy store and forward messaging such as the Short Messaging Service 
(SMS). 

Calls from non-human associated devices (e.g. fire alarms) are outside the scope of this specification. 



Adding, removing and modifying individual media to/from an IMS MES shall be supported. 

An IMS MES is not a subscription service. A UE capable of IMS emergency calls and capable of supporting the other 
media types should also be able to support initiation of an IMSMES. 
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An IMS MES from an unauthenticated UE (as far as the IM CN is concerned) shall be supported by the IM CN 
subsystem, if required by local regulation. 

IMS MES shall be supported by UEs that are subject to service restrictions, e.g. for UEs camping on a cell in a 
forbidden PLMN or in a forbidden LA (see 3GPP TS 22.01 1 [11]), or on a CSG cell without the subscriber being a 
member of that CSG (see 3GPP TS 22.220 [48]). Such IMS MES shall be accepted by the network if required by local 
regulation. 

An IMS MES shall support providing the location of the UE, in a manner similar to IMS emergency voice calls. 

An IMS UE that supports IMS MES shall identify an emergency number dialled by the end user as a valid emergency 
number utilizing the same mechanisms as used for IMS emergency voice calls as defined in subclause 10.1.1. 

NOTE 2: This capability supports the general public, including facilitating emergency communications by 

individuals with disabilities (e.g. persons who are deaf, deaf -blind, hard of hearing, or have a speech 
disability). 

An originating network and UE may support some or all of these other media types, and support of any specific media 
by an originating network or UE may be subject to regulatory requirements. 

Voice call continuity per clause 21 shall be supported when a UE with an active IMS MES with voice and other media 
moves out of IMS voice coverage and voice call continuity is supported by the UE and network. The remaining media 
(i.e. voice call) then becomes a CS emergency call e.g. TS12 call for 3GPP systems as defined in 3GPP TS 22.003 [14]. 

Other media shall be dropped when a UE with an active IMS MES moves out of IMS voice coverage, irrespective of 
whether or not there is an active voice session. 

10.4.2.2 UE Requirements 

When IMS MES are supported by the UE, the following apply: 

An IMS UE that supports IMS MES shall also support IMS emergency voice calls. 

Once a UE is aware that an IMS MES has been initiated, the UE shall be able to (subject to user configuration) 
avoid drawing unnecessary attention to the user (e.g., playing audible tones or flashing brightly) and should 
confirm this to the user in as private a manner as is reasonable e.g. using text on the screen or audio if 
headphones are already connected. UE behaviour in an IMS MES may need to be different relative to the 
normal configuration. 

The UE should clearly differentiate IMS emergency session-mode text based instant messaging from IMS non- 
emergency session-mode text based instant messaging on the user display. 

The IMS UE supporting video transfer during an IMS MES should be able to deliver recorded media in a form 
that allows progressive playback. (It is desirable that all pre-recorded media sent during an emergency session be 
progressively viewable.) 

When an IP PSAP attempts to add additional media to an existing IMS MES, the user shall be made aware of 
this. When additional media is requested by the PSAP, the user shall be able to permit or deny it. 

The UE shall provide an indication to the user for each requested media, whether it was successfully or 
unsuccessfully established. 

Further notifications of added and removed media shall be indicated to the user while the IMS MES is active. 

If none of the media requested by the UE is successfully established, the IMS MES will fail and an IMS MES 
failure indication shall be provided to the user. 

In handover of an IMS MES where other media is dropped when IMS MES is not supported, the UE shall 
indicate to the end user that the other media is not supported in this area. 

The following requirements for IMS emergency voice calls also apply when an IMS MES is supported by the UE: 

An IMS UE that supports IMS MES shall indicate to the network that the call is an IMS emergency call as is 
done for an IMS emergency voice call. 
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- An IMS UE that supports IMS MES shall be able to receive an IMS call-back from a PSAP per clause 10. 1 .3 
with voice, GTT or other media per clause 10.4.2.1. 

An IMS UE that supports MES shall utilize the same trust and security mechanisms for the other media as 
utilized for an IMS emergency voice call. 

When roaming, a UE shall originate an IMS MES in the serving network in the same manner as for IMS 
emergency voice calls. 

10.4.2.3 Originating Network Requirements 

When an IMS MES is enabled by the originating network, the following apply: 

Other media shall only be supported in packet-based networks that support IMS emergency voice calls. 

The originating network shall deliver all media to the same IP PSAP throughout the duration of the IMS MES. 

The network shall indicate to the UE, for each requested media, whether it was successfully or unsuccessfully 
established. 

Further notification of added and removed media shall be provided to the UE while the IMS MES is active. 

If none of the media requested by the UE is successfully established, the IMS MES will fail and an IMS MES 
failure indication will be provided to the UE. 

The following requirements for IMS emergency voice calls also apply when IMS MES is supported by the network: 

Subject to regional regulatory requirements, the network shall be able to authenticate the UE using the same 
procedures as for IMS emergency voice calls. 

The originating network shall provide the capability to enable an IMS UE supporting IMS MES to obtain local 
emergency numbers or other emergency address(es) (e.g. destination address) utilizing the same mechanism as 
used for IMS emergency voice calls. 

An IMS MES shall be provided in the local serving network. 

For an IMS MES, any kind of emergency addressing (e.g. SIP URIs, Tel URIs) and special indications for 
emergency sessions shall be treated in the same manner as IMS emergency voice calls. 

The originating network should detect all IMS MESs regardless of the UE emergency call indication. According 
to operator policy, the originating network may either inform the UE to enable re-origination as an IMS MES or 
support origination of the initial call. 

The originating network shall be responsible for routing the IMS MES towards the appropriate PSAP (e.g., based 
on emergency service type, location, or policy). 

The network shall be able to provide integrity protection, and/or privacy for other media similar to that provided 
for IMS emergency voice calls. 

An IMS MES shall utilize the same priority mechanisms as IMS emergency voice calls. 

Detailed log records of the IMS MES shall be generated by the originating network in a similar manner to IMS 
emergency voice calls and subject to regulatory requirements. 

All media content within the IMS MES shall be carried with an indication of the source, in a similar manner as 
for IMS emergency voice calls. 

10.5 Void 

1 0.6 Location Availability for Emergency Calls 

National regulations may require wireless networks to provide the emergency caller"s location. This requirement 
typically overrides the caller" s right to privacy with respect to their location being revealed, but remains in effect only 
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as long as the authorities need to determine the caller" s location. The interpretation of the duration of this privacy 
override may also be different, subject to national regulation. For example, some countries require location to be 
available from the wireless network only while the call is up, while others may allow PSAP"s to unilaterally decide how 
long the location must be made available. 

Therefore, the requirement for providing location availability is to allow the network to support providing a mobile 
caller"s location to the authorities for as long as required by the national regulation in force for that network. 

Note: See TS 22.071 [44] for location service requirements on emergency calls. 

1 0.7 Transfer of data during emergency calls 

Emergency calls may be supplemented with emergency related data [1]. Typically this data enables the accurate 
geographic location of a manually or automatically activated emergency calling device e.g. an in vehicle system (IVS), 
to be provided to the Public Safety Answering Point (PSAP). 

The following requirements apply to UEs designed to be able to perform transfer of data during an emergency call and 
to networks supporting transfer of data during an emergency call: 

The data may be sent prior to, in parallel with, or at the start of the voice component of an emergency call. 

Should the PSAP request additional data then this may be possible during the established emergency call. 

The realisation of the transfer of data during an emergency call shall minimise changes to the originating and 
transit networks. 

Both the voice and data components of the emergency call shall be routed to the same PSAP or designated 
emergency call centre. 

The transmission of the data shall be acknowledged and if necessary data shall be retransmitted. 

The UE shall indicate at call setup if the emergency call will carry supplementary data. 

UEs designed to be able to perform transfer data during emergency calls and configured to only perform emergency 
calls with transfer of data (eCall only mode) shall comply with the following additional requirements: 

TheUE shall not perform mobility management procedures, including registration on a PLMN, except when 
attempting to initiate and during an emergency call, or to initiate a test or reconfiguration of the terminal upon 
request from the user. 

For UEs that have the ability to be called back by the PSAP, the UE shall be capable to continue mobility 
management procedures for a limited duration following the termination of the eCall. 

The UE shall contain an USIM application. 

In the case where the user subscribes to other services provided by the PLMN, it shall be possible for the 
network operator to reconfigure the UE so that it can access the subscribed services. 

It shall be possible for the user of the UE to change network operator/service provider (i.e. to use a different 
USIM) or for the subscriber to modify the existing subscription used with the UE. 

It shall be possible for the UE upon request from the user to initiate a call to an operator designated non- 
emergency MSISDN for the purpose of accessing test and terminal reconfiguration services. 

Additional national and regional requirements are as specified in Annex A. 

1 0.8 Supplementary service interaction during emergency calls 

Supplementary services that interrupt or divert the media path between a PSAP and the end device shall be handled as 
specified in TS 22.173 [40] (e.g. Communication Hold) for Multimedia Telephony. No such Supplementary Services 
are applicable to CS Emergency Calls (TS12) according to TS 22.004 [5]. 
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11 Numbering principles 

The following network addressing schemes listed below shall be supported at the relevant domains: 

- E.164, 

- E.168, 

- E.212, 

- X.121 

Internet (including e.g. IP address, SIP URI). 

11.1 Number portability 

11.1.1 Requirements for CS CN domain 

Some numbering schemes shall be fully independent of the supporting serving network and the home environment, 
allowing users to transfer this number to another home environment. For further information see 3GPP TS 22.066 [7]. 

An MSISDN shall be allocated to each new user at the start of a subscription. This number may be allocated from one 
of several numbering domains. For example: 

home / serving environment numbering scheme; 

national numbering scheme; 

regional numbering scheme; 

global numbering scheme. 

A user shall be able to move subscription from one home environment to another without changing the MSISDN 
provided that the new home environment offers service in the same geographic domain. It is envisaged that home 
environment s will be able to allocate MSISDNs from each of these domains as required. 

11.1.2 Requirements for PS CN domain 

None identified. 

1 1 .1 .3 Requirements for IM CN subsystem 

It shall be possible to offer number portability for E. 164 numbers within IM CN subsystem. For further information see 
3GPPTS 22.066 [7]. 

1 1 .2 Evolution path 

Since 3GPP specifications aim to be aligned with IMT-2000, a primary goal in numbering is the provision of global 
user numbering in line with steps taken by the ITU - SG2. 

The numbering scheme and network implementation chosen shall allow for international/global evolution. 
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1 1 .3 Void 

1 1 .4 Void 

1 1 .5 Void 

1 1 .6 Private numbering 

A user may wish to use private numbers for the purposes of calUng frequent numbers. Therefore there is a requirement 
for the use, by the user, of Private Numbering Plans (PNPs). These schemes may belong to the user himself, to a home 
environment or a third party. 

11.7 Numbering schemes 

11.7.1 IVIultiple numbering scheme 

The standards shall support the possiblity of allowing the bearer service associated with an MT call to be implicitly 
defined by the destination MSISDN, for example to use a different MSISDN to establish voice, fax or data . It will be 
possible for multiple MSISDNs to be associated with a single subscription. 

11.7.2 Single numbering scheme 

The standards shall support the possibility of allowing MT calls of different bearer types (eg voice, fax, data) to be 
routed to a single MSISDN. It is recognised that the implementation of this may depend on the availability of bearer 
information associated with an incoming call from the adjoining transit network. In particular the standards will support 
this possibility in the case of an adjoining ISDN transit network. 

11.7.3 Additional numbers 

The 3GPP system shall support the possibility to assign an additional MSISDN, in addition to the original MSISDN, to 
a user with a connection to the PS CN domain. If this additional MSISDN is available it shall be used for correlation of 
CS and IMS in voice call and service continuity as well as IMS Centralized Service. In this case the original MSISDN 
may be used for charging and OA&M purposes and forwarded to the PS gateway to other packet data networks. 



1 1 .8 Optimal routing 



The implementation of the numbering scheme used shall allow for optimal routing; i.e. routing shall not take place 
simply on the number dialled. 

See 3GPP TS 22.079 [8] for some scenarios for the CS CN domain. Optimal routing for IP services is supported by the 
All-IP Network [42]. 



11a Identification Requirements 
1 1 a. 1 Subscriber Identification 

In 3GPP the identity of a subscriber is encoded in a identity module application which is contained on a UICC or on a 
GSM SIM card. The UICC or GSM SIM card is a removable component of the User Equipment. Three types of 
identity modules are used in the 3GPP system: 

- Universal Subscriber Identity Module (USIM) 

- IMS Subscriber Identity Module (ISIM) 
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- Subscriber Identity Module (SIM) according to GSM 

General requirements: 

In the 3GPP system each subscriber shall be uniquely identifiable. 

The serving networks shall be able to authenticate any subscriber that roams onto their network 

If a UE, that is registered on the serving network, contains a GSM SIM card or a UICC containing a identity 
module application, the serving network shall be able to identify the associated home PLMN. 

Note 1: UE support of GSM SIM is optional. 

Note 2: See the chapter (USIM, UICC and Terminal) of the present specification for a reference, which GSM 
phase SIMs need to be supported by the network. 

11a.2 Terminal Identification 

It is a requirement that the terminal can be uniquely identified by the home environment and serving network. This 
shall require a terminal identity scheme which uniquely identifies each terminal, see 3GPP TS 22.016[12]. 

1 1 a.3 Home Environment / Serving Network Identification 

Home / serving environments need to route communication to the current location of the user. This shall require a 
identity scheme which uniquely identifies the serving environment and shall be used for routing purposes. 

1 1 a.4 Serving Environment / Mobile Virtual Network Identification 

A mobile virtual network operator (MVNO) is a service provider that does not have its own radio access network, but 
resells wireless services, typically under their own brand name, using the network of a host PLMN operator. 

It should be possible to uniquely identify subscribers belonging to a particular MVNO. 



12 Human Factors and user procedures 

The User Interface (MMI) from the end-user"s point of view should be as flexible as possible while still meeting the 
general service requirements. In addition it should be capable of being updated so as to meet new services which are 
still to be envisaged. 

In general the following principles should be encompassed: 

activation of services should be as simple as possible with minimum input expected from the user; 

feedback, to the user from the various services, should be meaningful; 

any error recovery procedures provided should be simple to understand and execute. 

input from the user and information to the user should be provided in alternative selectable modes in order to 
match user capabilities, preferences and situation. 

However, a detailed specification for the User Interface shall not be defined. In particular given the global nature of the 
third generation systems, for different regions of the world, different criteria will determine the implementation of the 
User Interface. Also it is unlikely that there will be a single common handset which will meet all the service 
requirements and therefore a common User Interface would be impractical. 

Given the flexibility of the services, there should be a wide range of User Interface possibilities. These possibilities 
include simple terminals with a single on/off button through to complex terminals providing support to hearing/visually 
impaired users. 
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Control of CS CN Domain supplementary services (3GPP TS 22.004 [5]), may use MMI procedures specified in 3GPP 
TS 22.030 [6] and existing MMI related UE features (Annex A) may also be used. In particular the following features 
are highly desirable for uniform UE implementation where appropriate: 

Mapping of numeric keys to European alphabetic keys to ensure compatible mnemonic dialing as defined in 
3GPPTS 22.030 [6], 

"+" key function to enable one key international access as defined in Annex A 

- Structure of the MMI as described in 3GPP TS 22.030 [6] 

Presentation of IMEI (International Mobile Equipment Identity) as defined in 3GPP TS 22.030 [6] 



13 UICC, USIM and Terminal 



This clause defines the functional characteristics and requirements of the User Service Identity Module (USIM) and 
ISIM (IM Services Identity Module). The USIM/ISIM are applications residing on a UICC. 

13.1 The USIM/ISIM and User Profiles 

13.1.1 The USIM 

Every USIM shall have a unique identity and shall be associated with one and only one home environment. 

It shall be possible for a home environment to uniquely identify a user by the USIM. 

The USIM shall be used to provide security features. 

For access to services, provided by PS or CS CN domains, a valid USIM shall be required. Optionally, SIM according 
to GSM phase 2, GSM phase 2+, 3GPP release 99, 3GPP release 4 specifications may be supported. 

The USIM shall be able to support SIM Application Toolkit as specified in 3GPP TS 22.038 [3]. 

The USIM shall reside on a UICC. USIM specific information shall be protected against unauthorised access or 
alteration. 

It shall be possible to update USIM specific information via the air interface, in a secure manner. 

Access to the IMS services shall be possible using the USIM application in the event of no ISIM being present on the 
UICC. If an ISIM is present on the UICC it shall be used to access the IMS. 

It shall be possible to store provisioning parameters on the USIM according to DM specifications [37]. 

It should be possible to store provisioning parameters on the USIM according to CP specifications [38]. 

It shall be possible for the network operator to configure the USIM to indicate (through personalisation and OTA) 
whether provisioning parameters according to DM specifications or provisioning parameters according to CP 
specifications shall be used. 

NOTE: To avoid misoperation of the UE in a mixed provisioning environment e.g. during a transition phase when 
both CP and DM clients are present in the UE, the CP parameters on the USIM can be read first. If 
DMinformation is present (provisioned OTA in the CP parameters.), then use DM, otherwise use CP. 

Annex A describes a number of features that may optionally be supported by the UE and thus USIM. 

13.1.2 User Profiles 

It shall be possible for a user to be associated with one or a number of user profiles, which the user can select and 
activate on a per call basis. The user profile contains information which may be used to personalise services for the 
user. 
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It shall be possible for one or more user profiles associated with the same user to be active simultaneously so that the 
user may make or receive calls associated with different profiles simultaneously. Activation of profiles shall be done in 
a secure manner, for example with the use of a PIN. 

For terminating calls the correct profile shall be indicated by the user address used (e.g. MSISDN, SIP URI), each 
profile will have at least one unique user address associated with it. For originating calls the user shall be able to choose 
from the available profiles, the appropriate one for the call. A profile identity will need to be associated with the call for 
accounting and billing purposes. User profile identities need not be standardised but a standardised means is required 
for indicating that a particular profile is being used. 

Simultaneous use of the same user profile on multiple terminals for the same type of service shall not be allowed. 

User profiles associated with different home environments shall not share the same user address. 

1 3.1 .3 UICC usage in GERAN only Terminals 

In Release 5 and later, terminals supporting only GERAN shall support USIM. 

Note: It is strongly recommended that manufacturers implement SIM support on GERAN only terminals until 
the population of SIMs in the market is reduced to a low level. 



13.1.4 Multiple USIMs per UICC 



The standard shall support more than one USIM per UICC even when those USIMs are associated with different home 
environments. Only one of the USIMs or the SIM shall be active at a given time. While the UE is in idle mode, it shall 
be possible for the user to select/reselect one USIM application amongst those available on the UICC. At switch on, the 
Last Active USIM shall be automatically selected. The Last Active USIM shall be stored on the UICC. By default if 
there is no Last Active USIM defined in the UICC, the user shall be able to select the active USIM amongst those 
available on the UICC. 

The standard must not prevent the coexistence of USIM applications, each associated with different home environments 
on the same UICC, so long as the security problems which arise from such a coexistence are solved. 

13.1.5 ThelSIM 

Access to the IMS services shall be possible using an ISIM application. 

The ISIM shall be sufficient for providing the necessary security features for the IMS and IMS only. 

The ISIM shall reside on a UICC. ISIM specific information shall be protected against unauthorised access or alteration. 

It shall be possible to update ISIM specific information via the air interface, in a secure manner. 

Note: When accessing IMS over GERAN/UTRAN/EUTRAN or I-WLAN using ISIM, a USIM needs also be 
present to access the rest of the 3GPP system. Alternatively USIM could be used to access IMS. 

13.2 The UICC 

Characteristics including physical formats of a UICC are defined in TS 31.101[36]. 
Access to services via 3GPP system with a single UICC shall be possible. 

1 3.2.1 The UICC and Applications other than the USIM or ISIM 

It shall be possible for the UICC to host other applications in addition to the USIM or ISIM, see figure 3. Service 
providers, subscribers or users may need to establish additional data or processes on the UICC. Each application on an 
UICC shall reside in its own domain (physical or logical). It shall be possible to manage each application on the card 
separately. The security and operation of an application in any domain shall not be compromised by an application 
running in a different domain. Applications may need to use their own security mechanisms which are separate to those 
specified by 3GPP e.g. electronic commerce applications. 
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Examples of UICC applications are: USIM, ISIM, off-line user applications like UPT, electronic banking, credit 

service, etc. 

Applications should be able to share some information such as a common address book. 
It shall be possible to address applications, which reside on the UICC, via the air interface. 
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Figure 3 Example of a Multifunction UICC 

1 3.2.1 a UICC applications and IMS 

UICC applications may make use of IMS functionalities controlled by ME. 

Note: This is to allow a UICC application to interact with an Application Server (AS) through IMS. Examples of 
UICC applications include identity management, banking applications, etc. 

1 3.2.2 Fast Access and Retrieval of Data from UICC 

An optional "high speed" interface may be provided between the UICC and the ME. 

If provided, this interface shall allow fast access and retrieval of data to support functionalities requiring large amounts 
of data to be transfered to and from the UICC. Examples include: 

on-card web servers 

rapid access to data stored on the UICC, e.g. phone book, PLMN lists or user data 

A UICC/ME interface supporting this "high speed" interface shall be backward compatible with the TS 102 221 
interface specified in 3GPP TS 31.101 [36]. 



13.3 Terminals and Multiple UlCCs 



A single terminal may support the use of multiple UICC (e.g with applications like USIM and/or banking, credit 
card,...). Only one UICC shall be active at a time to access a PLMN. In case the active UICC contains more than one 
USIM, the requirements of 13.1.4 shall apply. 

If the UICC with the active USIM is removed from the mobile terminal during a call (except for emergency calls), the 
call shall be terminated immediately. If the UICC with an active ISIM is removed during an IMS session the IMS 
session shall be terminated. 



1 4 Types of features of UEs 



3GPP specifications should support a wide variety of user equipment, i.e. setting any limitations on terminals should be 
avoided as much as possible. For example user equipment like hand-portable phones, personal digital assistants and 
laptop computers can clearly be seen as likely terminals. 
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In order not to limit the possible types of user equipment they are not standardised. The UE types could be categorised 
by their service capabilities rather than by their physical characteristics. Typical examples are speech only UE, 
narrowband data UE, wideband data UE, data and speech UE, etc. 

In order to enhance functionality split and modularity inside the user equipment the interfaces of UE should be 
identified. Interfaces like UlCC-interface, PCMCIA-interface and other PC -interfaces, including software interfaces, 
should be covered by references to the applicable interface standards. 

UEs have to be capable of supporting a wide variety of teleservices, multimedia services and applications provided in 
PLMN environment. Limitations may exist on UEs capability to support all possible teleservices, multimedia services 
and information types (speech, narrowband data, wideband data, video, etc.) and therefore functionality to indicate 
capabilities of a UE shall be specified. 

The basic mandatory UE requirements are: 

- Support for USIM. Optional support of GSM phase 2, 2+, 3GPP Release 99 and Release 4 SIM cards [34]. 
Phase 1, 5V SIM cards shall not be supported. Support for the SIM/ISIM is optional for the UE, however, if it is 
supported, the mandatory requirements for SIM/ISIM shall be supported in the UE; 

Note 1: There is no Release 5 specification for the SIM, and therefore references to "SIM" apply to earlier 
releases. 

Note 2: It is strongly recommended that manufacturers implement SIM support on terminals supporting GERAN 
until the population of SIMs in the market is reduced to a low level. 

Home environment and serving network registration and deregistration; 

Location update; 

Originating or receiving a connection oriented or a connectionless service; 

An unalterable equipment identification; IMEI, see 3GPP TS 22.016 [12]; 

Basic identification of the terminal capabilities related to services such as; the support for software downloading, 
application execution environment/interface, MExE terminal class, supported bearer services. 

Terminals capable for emergency calls shall support emergency call without a SIM/USIM/ISIM. 

Support for the execution of algorithms required for encryption, for CS and PS services. Support for non 
encrypted mode is required; 

Support for the method of handling automatic calling repeat attempt restrictions as specified in 3GPP TS 22.001 
[4]; 

At least one capability type shall be standardised for mobile terminals supporting the GERAN, UTRAN and E- 
UTRAN radio interfaces. 

Under emergency situations, it may be desirable for the operator to prevent UE users from making access 
attempts (including emergency call attempts) or responding to pages in specified areas of a network, see 3GPP 

TS 22.011 [11]; 

Ciphering Indicator for terminals with a suitable display; 

The ciphering indicator feature allows the UE to detect that the 3GPP radio interface ciphering (user plane) is not 
switched on and to indicate this to the user. The ciphering indicator feature may be disabled by the home 
network operator setting data in the SIM/USIM. The default terminal behaviour shall be to take into account the 
operator setting data in the SIM/USIM. However, terminals with a user interface that can allow it, shall offer the 
possibility for the user to configure the terminal to ignore the operator setting data in the SIM/USIM. If this 
feature is not disabled by the SIM/USIM or if the terminal has been configured to ignore the operator setting data 
in the SIM/USIM, then whenever a user plane connection is in place, which is, or becomes un-enciphered, an 
indication shall be given to the user. In addition, if this feature is not disabled by the SIM/USIM or if the 
terminal has been configured to ignore the operator setting data in the SIM/USIM, then additional information 
may also be provided about the status of the ciphering. Ciphering itself is unaffected by this feature, and the user 
can choose how to proceed; 

Support for PLMN selection. 
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Support for handling of interactions between toolkits concerning the access to UE MMI input/output capabihties; 

Whenever an application (e.g. a SAT/MExEAVAP application) requires the access to the UE MMI input/output 
capabilities (e.g. display, keyboard,... ), the UE shall grant this access subject to the capabilities of the UE. This 
shall not cause the termination of any other applications (e.g. WAP browser or MExE/SAT application) which 
were previously using these UE resources. The UE shall give the user the ability to accept or reject the new 
application. In the case that the application request is rejected, the access to the UE MMI input/output 
capabilities is returned to the applications which were previously using these UE resources. If the user decides 
to continue with the new application, then when this new application is terminated, the access to the UE MMI 
input/output capabilities shall be returned to the UE to be re-allocated to applications (e.g. the preceding 
application which was interrupted). Subject to the capabilities of the UE, the user shall have the ability to switch 
the MMI input/output capabilities between applications. 

Note: Rejecting a request to access the UE MMI input/output capabilities by an application does not 

necessarily mean that it is terminated, but only that the access to the UE MMI input/output capabilities 
are not granted to this application. Handling of rejection (termination, put on hold,...) is the responsibility 
of the application. 

Annex A describes a number of features which may optionally be supported by the UE. 



15 Relationship between subscription and service 
delivery 



15.1 Subscription 



A subscription describes the commercial relationship between the subscriber and the service provider. 



Subscriber 



Subscription! Subscription 2 Subscriptions ■" Subscription n 




Figure 4: Subscriber, subscription and services relationship 



A subscription to a network operator may provide the user with access to one or more domains. A Subscription shall 
identify the set of services, within particular domains, to which the user has access (see figure 3); each subscription may 
specify a different set of services. These services may be provided by the CS CN Domain and/or a PS CN Domain 
and/or an IM CN subsystem. Subscriptions relate to services such as Basic Services (e.g. Teleservices, Bearer services), 
PS services and IM-Services (IP -based multimedia services), which are typically provided by network operators, and to 
value added services which typically are provided by network operators and/or other entities that provide services to a 
subscriber 

The subscription identifies: 
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the services and related services information that are made available to the subscriber by the service provider ; 

In addition a subscription to a network operator may identify: 

the domains to which the user has been granted access by the network operator. In particular, the PS service 
profile and information on the allowed QoS parameter ranges shall be contained in the subscription. 

the identity of the subscriber within these domains. 

Note: The identity of a subscriber in the CS CN domain and PS CN domain (e.g. her IMSI) may potentially be 

different to her identity in the IM CN subsystem 

the radio access systems over which the subscriber may access their services e.g. UTRAN, GERAN, EUTRAN, 
I-WLAN. 



1 5.2 Other concepts associated with services 

Provision of services: 

An action to make a service available to a subscriber. The provision may be: 

general: where the service is made available to all subscribers (subject to compatibility restrictions 
enforced) without prior arrangements being made with the service provider; 

pre-arranged: where the service is made available to an individual subscriber only after the necessary 
arrangements have been made with the service provider. 

Withdrawal: 

An action taken by the service provider to remove an available service from a subscriber's access. The withdrawal may 
be: 

general: where the service is removed from all subscribers provided with the service; 

specific: where the service is removed on an individual basis from subscribers provided with the service. 



NOTE: Access to the IM subsystem requires IP connectivity provided, for example, through provision of the PS 
CN domain. 

1 5.3 Requirements concerning service delivery 

In general it is a requirement to allow the use of independent services simultaneously (i.e. Basic, PS, IP multimedia and 
operator specific). 

1 . The network usage shall be based on the services identified within the subscription, the terminal capabilities and, 
where applicable, roaming agreements between operators. 

2. The Home environment shall be able to decide on the service delivery in a roaming scenario. I.e. it shall control 
how services are delivered in line with the subscription. 

3. If an offered or required service (e.g. voice) could be provided with different technologies within the serving 
network, the decision on service delivery shall be based on preferences identified in the user profile and serving 
network capabilities and conditions (e.g. load). 

4. If the user profile does not allow an alternative service delivery method and the requested delivery method is not 
available in the serving network the service shall not be provided to the subscriber. This applies also to data bearer 
services with defined QoS parameters (or parameter ranges). 

Examples: 

A terminating voice call for a subscriber with a dual/multi mode terminal (e.g.UTRAN/GERAN) could be 
delivered in a hybrid network as IM service or CS voice call (TSll). The delivery decision is based on the 
preferences of service delivery within the user profile and the network conditions. If there is no preference 
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information of the Home environment available the decision is made only on the network conditions from the 
serving network. 

A terminating data service (e.g. PS with QoS for real time audio) where the network cannot provide the QoS at 
call setup. Both the originating and terminating application shall be informed about the possible QoS 
configuration for that call. The further handling (setup continuation, termination) depends on the decisions of the 
applications. 

1 5.3.1 Mobile Originated Voice calls 

When a ME capable of offering voice service both on CS and IMS is CS attached and IMS registered MO CS Voice 
calls (TSll) and MO IMS voice services shall be originated on the domain specified by the Home operator policy or 
users preferences. The Home Operator policy shall have precedence to user preferences. 

1 5.3.2 Mobile Terminated Voice calls 

When a ME capable of offering voice service both on CS and IMS, MT CS Voice calls (TS 11) and MT IMS voice 
services shall be delivered over the domain specified by the Home operator policy or users preferences. The Home 
Operator policy shall have precedence to user preferences. If the call delivery attempt fails in one domain, if specified 
by operator policy, it should be possible to attempt the delivery in the other domain or the call/communication 
forwarding supplementary services [41, 40] maybe invoked if provisioned. 

Note: The delivery decision will take into account aspects such as IMS registration and CS attachment status. 



16 Charging principles 



The cost of the call may cover the cost of sending, transporting, delivery and storage. The cost of call related signalling 
may also be included. Provision shall be made for charging based on time, destination, location, volume, bandwidth, 
access technology and quality. Charges may also be levied as a result of the use of value added services. 

It shall be possible for information relating to chargeable events to be made available to the home environment at short 
notice. The requirements shall include: 

Immediately after a chargeable event is completed; 

At regular intervals of time, volume or charge during a chargeable event. 

Delivery of the location of the terminal to the home environment, e.g. cell identification; 

Standardised mechanisms of transferring charging information are required to make these requirements possible. 

It should be possible for multiple leg calls (e.g. forwarded, conference or roamed) to be charged to each party as if each 
leg was separately initiated. However, in certain types of call, the originating party may wish/be obliged to pay for other 
legs (e.g. SMS MO may also pay for the MT leg.). 

It shall be possible to charge according to the location (e.g. cell, or zone) and access technology that are being used to 
access network services. 

Provision shall be made for the chargeable party to be changed during the life of the call. There shall be a flexible 
billing mechanism which may include the use of stored value cards, credit cards or similar devices. 

The chargeable party (normally the calling party) shall be provided with an indication of the charges to be levied (e.g. 
via the called number automatically or the Advice of Charge supplementary service) for the duration of the call (even 
though the user may change service environment)The user shall be able to make decisions about the acceptable level of 
accumulated charge dynamically or through their service profile. 

If a user is to be charged for accepting a call then their consent should be obtained. This may be done dynamically or 
through their service profile. 

Charging and accounting solutions shall support the shared network architecture so that end users can be appropriately 
charged for their usage of the shared network, and network sharing partners can be allocated their share of the costs of 
the shared network resources. 
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17 Roaming 
17.1 Assumptions 

In order to roam, the following applies: 

Mobile terminal can connect to the radio access network. 

Authentication (charging/billing network) must occur in order to get access to services (except for emergency 
calls). 

The services offered to a roaming subscriber may be restricted by the capabilities of the visited network, and the 
roaming agreement between the visited and the home environment. 



17.2 Principle 



Long term evolution of the IM CN subsystem shall not be restricted by the short/mid term inter-domain roaming 
requirements. 



17.3 Requirements 



Home Environment 




Visited Networks 

Figure 5: Roaming requirements 

The personalised services & capabilities available in a visited network are dependent upon the subscription 
options in the home environment. This does not preclude the visited network offering additional services, or 
access to content providers. 

Roaming from this release's home environment to CS (this release or earlier) visited network is required 

Roaming from this release's home environment to IM CN subsystem visited network is required 

Roaming from this release's home environment to PS (this release or earlier) visited network is required 

Roaming from previous releases' home environment (or earlier) to this release CS visited network is required 

Roaming from previous releases' home environment (or earlier) to this release PS visited network is required 
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Note: When an operator allows a subscriber to roam to different domains, the home environment needs to 
provide subscription data to the visited network . The mapping between service data of the different 
domains is not standardised; it is determined by the home environment and may be influenced by roaming 
agreements. 



18 Handover Requirements 



Any handover required to maintain an active service while a user is mobile within the coverage area of a given network, 
shall be seamless from the user"s perspective. However handovers that occur between different radio environments may 
result in a change of the quality of service experienced by the user. 

It shall be possible for users to be handed over between different networks subject to appropriate roaming/commercial 
agreements. 

For further information see 3GPP TS 22.129 [9]. 



19 Network Selection 

Network selection procedures are defined in 3GPP TS 22.01 1 [11]. 
Other procedures may be offered by the UE. 

20 Security 

Security matters are considered in 3GPP TS 21.133 [15] and 3GPP TS 33.120 [16]. 



21 Voice Call Continuity 

21.1 General 

The 3GPP system shall be able to provide continuity between CS voice services (Teleservice 1 1 [14]) and the full 
duplex speech component of IMS multimedia telephony service [40] with no negative impact upon the user"s 
experience of the voice service. This functionality is known as voice call continuity. Voice call continuity shall be 
executed when continuation of a voice service is required based on operator policy across a change in the connection of 
the UE to the 3GPP system as the user moves from using the CS domain to using IMS and vice versa. 

The user experience shall be unaffected by the transition from a CS voice service to a full duplex speech component of 
IMS multimedia telephony and vice versa, and the user shall experience no disruption in the voice service provided. 
The voice service is continued with the same ME. 

It shall be possible to support Voice call continuity between IMS and the CS domain belonging to different operators; 
i.e., when the user"s IMS services are under the control of the home IMS and the user is roaming in the coverage of the 
visited CS network. 

It shall be possible for an operator to enable or disable Voice call continuity for a given subscriber e.g. based on 
roaming conditions, terminal capabilities. 

21 .2 Support of Supplementary Services 

The voice call continuity user"s experience shall be such that, to the greatest degree possible, a consistency of service is 
provided regardless of the underlying communication infrastructure and technology. With regard to supplementary 
services, the general principle is that CS-based supplementary services only apply whilst a VCC subscriber is in the CS 
domain and equivalent services over IMS only apply whilst a VCC subscriber is in the IMS domain, although there are 
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exceptions listed below. It is not required to synchronise the supplementary service settings of the CS domain with the 
related service settings of the IMS (e.g. different forwarding numbers may apply over CS and over IMS). 

The following supplementary services apply. The impact on the supplementary services in case the VCC is executed for 
the calling party, the called party, or both is described below. 

21 .2.1 Line Identification Services 

A user who has subscribed to the CLIP Supplementary Service and receives a call shall also receive the line identity or 
appropriate IMS information of the calling party. 

The identity presentation is not changed for the duration of the call regardless of whether the call undergoes VCC. 

If the CLIR Supplementary Service or IMS identity restriction is applicable to the call, then at call setup time the called 
user shall receive an indication that the identity is not available because of restriction. 

The indication is not changed for the duration of the call regardless of whether the call undergoes VCC. 

If COLP or a corresponding IMS service is applicable to a call the calling subscriber shall receive the connected line 
identity or appropriate IMS information at call setup time. 

The identity presentation is not changed for the duration of the call regardless of whether the call undergoes VCC. 

If the COLR Supplementary Service or IMS identity restriction is applicable to the call, then the calling user shall 
receive an indication at call setup time that the identity of the connected party is not available because of restriction. 

The indication is not changed for the duration of the call regardless of whether the call undergoes VCC. 

21.2.2 All Call Forwardings 

It shall be possible to perform VCC on a call which was forwarded due to call forwarding supplementary services in the 
CS or redirecting services in the IMS. 

21.2.3 Call Waiting 

The functionality of call waiting supplementary service in the CS domain shall not be affected by the user"s ability to 
undergo VCC. 

Note: Whether the user will continue to receive call waiting notifications in the case their call is continued in 
the IMS will depend on whether a call waiting service is available in the IMS. 

21.2.4 Call Hold 

It shall be possible to re-establish a call which has been put on hold before undergoing VCC, after the VCC has been 
performed. 



21.2.5 Multiparty 



It shall be possible for any party in a multiparty call to undergo VCC and to stay in the call. It shall be possible to 
terminate the entire multiparty call when the served mobile subscriber releases even if she is connected via the IMS 
after undergoing VCC. 



21.2.6 All Call Barrings 



If a call were to undergo VCC and that would result in the call being barred in the target domain/system, it shall be up 
to the home operator policy whether the call continues in the target domain/system, the call terminates, or VCC is not 
executed for the call. 
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21.2.7 Void 

21.2.8 Void 

21 .2.9 All other Supplementary Services 

Other supplementary services are not discussed in this section as they do not apply to calls in progress (i.e. they apply to 
call set up only) or their support and/or the need for standardised implementation has not been identified as critical for 
VCC in this Release. 

21 .3 Quality of Service 

Voice call continuity shall not adversely impact the quality of the voice service experienced by the user. 

21.4 Security 

Voice call continuity shall not adversely impact the security of the 3GPP system. 
Security mechanisms of the 3GPP system shall be reused for voice call continuity. 

21.5 Emergency calls 

Voice call continuity for emergency calls shall be applicable to dual radio and single radio UEs. 

Voice call continuity of emergency calls shall only be performed when all the following conditions are met: 

the source network is IMS; 

the target network supports emergency calls; 
- the user is moving out of coverage; 

the source and target network belong to the same operator; 

the target network supports voice call continuity. 



21.6 Charging 



It shall be possible to indicate in the charging information that a VCC event has occurred (e.g., so that appropriate 
ratings can be applied for the CS and IMS parts of the continued voice call). 

21.7 VCC Activation 

It shall be possible to activate VCC based on operator policies, taking into account any of the following: 
Radio conditions e.g. radio quality thresholds and related hysteresis 
Coverage availability e.g: Always prefer I-WLAN, if certain SSID are available 
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22 IMS Centralized Services 

22.1 General 

The ICS user shall receive both registered and unregistered services in a consistent manner when the user accesses IMS 
either via the CS or the PS domain (both of which can be supported by 3GPP access networks or non-3GPP access 
networks). Support of UEs enhanced with ICS capability as well as UEs without ICS capability shall be possible. 

NOTE: The impacts to support non-3GPP CS domains to support of ICS are outside the scope of 3GPP. 

22.2 Service Consistency 

Subscribers shall have a consistent user experience regardless of the domain used, subject to the constraints of the UE 
and access network. 



22.3 Service Continuity 



ICS shall support service continuity between CS and PS domains (both of which can be supported by 3GPP access 
networks or non-3GPP access networks), subject to the constraints of the UE and access networks. 

Note : The impacts to support non 3GPP CS domains are outside the scope of 3GPP. 

The service continuity shall include: 

Basic services 

Non mid-call services 

Mid-call services 
The support of service continuity for fax and data (CS) media components is not required. 



22.4 IMS Services 



The set of IMS services supported by ICS shall include at least the following, subject to the constraints of the UE and 
access networks: 

- IMS Multimedia Telephony services, including: 

- speech, 

- video, 

- fax, 

- data (CS), 

- Supplementary services defined within [40]; and 

- Multimedia priority service. 

Note: Other IMS hosted services supported by an operator or 3rd party may be supported. 
ICS shall not limit the ICS user"s capability to make emergency calls 



22.5 Roaming Support 



An ICS user shall be able to receive full ICS support from the HPLMN while roaming in the VPLMN, subject to the 
constraints of the VPLMN (e.g. roaming agreements, operator policies). 



£75/ 



3GPP TS 22.1 01 version 1 1 .9.0 Release 1 1 44 ETSI TS 1 22 1 01 V1 1 .9.0 (201 3-07) 

The Home operator shall be able to control if the UE enhanced with ICS capability shall act without ICS capability 
while roaming. 



23 CS IP interconnection requirements 
23.1 Introduction 

CS IP interconnect represents the interconnection of MSC Server functionality between 2 CS networks over an 
underlying IP infrastructure. 



23.2 IP interconnect 



The IP connection used for CS IP interconnect shall be generic such that it can support all combinations of core network 
interconnection. E.g. the IP interconnection shall be shared between the IMS interconnection and the CS IP 
interconnection. 

It shall be possible to handle the inter-connection of all services over this generic IP interface. The handling of security 
and charging shall also be generic for all IP interconnect scenarios. 

23.3 MSC server interconnect 

The following requirements apply at the interconnection point when two PLMNs are interconnected by means of IP 
transport technology for 2G and 3G CS services. 

The system shall support the capability for CS service interoperability and interworking. 

It shall be possible to apply operator defined policy at the interconnection point. 

The system shall support the capability to control the session resources when two different network domains are 
connected that may have, for example, different IP addressing schemes. 

The system shall support IP inter-connection between core networks either by direct connection or by using an 
intermediate carrier (e.g. GSMA IPX [43]). 

The system shall support both bilateral interconnection between two carriers and multilateral interconnection (e.g 
GSMA IPX [43]) by means of intermediate carrier. 

The system shall support either 

transparent relay of the IP signalling and traffic; 

service aware interconnection 

The system shall support codec negotiation across one or multiple interconnects to minimise transcoding (and 
preferably eliminate it) to provide the highest quality service to the user. 



24 Service Alignment & Migration 
24.1 Introduction 

Services can be offered to the users via different service domains, e.g. certain teleservices and supplementary services 
via CS or Multimedia Telephony and supplementary services via IMS. Especially for the supplementary services given 
below a strong relationship exists from the user's point of view. Therefore means shall be provided to enable a 
consistent user experience when changing from one service domain to the other. 
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The requirements in this clause are apphcable during the migration to an ICS. The ability to synchronise the service 
settings will facilitate the migration from a CS to an IMS based network and will allow network operators maximum 
flexibility in their migration strategies. 

24.2 Alignment of supplementary services settings 

Based on user preferences and if provisioned by the home operator the network shall automatically synchronise the 
parameter settings of the supplementary services listed in the following table: 

Table 24.2-1 : Alignment of supplementary services settings 



CS Voice (TS11) 
Supplementary Services 


Equivalent Multimedia 

Telephony Services in 

IMS domain 


Service Behaviour Required 


CLIP/CLIR 


OIP/OIR 


Consistency of presentation 


CoLP/CoLR 


TIP/TIR 


Consistency of presentation 


CNAP 


OIP/OIR 


Consistency of presentation 


Call Forwarding 


CDIV 


Call forwarding/CDIV shall work consistently no matter 
which domain the user is in. The settings (e.g. forwarding 
numbers) shall remain the same across domains for all the 
parts of the service for which there is an equivalent. 


Call Waiting 


Communication Waiting 


The busy state of the user shall be available to both 
domains so that this can be applied no matter from which 
domain an incoming call/communication originates. The 
activation status of Call Waiting and Communication 
Waiting shall be synchronised. 


Call Hold 


Communication HOLD 


Any calls held in one domain shall remain held on moving 
to a different domain. It shall be possible to re-establish a 
call that was put on hold in another domain. 


Multiparty 


CONF 


Any conference (multiparty) calls set up in one domain 
shall remain in force if any user moves to another domain. 


Closed User Group 


Closed User Group 


Consistency required across domains 


CCBS 


CCBS 


Consistency required across domains 


Call Deflection 


Defined in CDIV 


Consistency required across domains 


Explicit Call Transfer 


ECommT 


Consistency required across domains. The UE state (i.e. if 
busy or not) shall be available in both domains to ensure 
that this can be applied consistently. 


Call Barring 


Communication Barring 


Call/ Communication Barring shall work consistently no 
matter which domain the user is in. The settings (i.e. 
barred numbers) shall remain the same across domains. 


AoC 


AoC 


Consistent support across domains. If the user moves 
from one domain to the other during the communication, 
the AoC shall indicate the correct charge for the total 
duration of the communication. 



The operator shall be able to provision the user with the possibility to define which of the above settings shall be 
synchronised automatically and which settings can exist independently of each other. E.g. a user might decide that the 
activation status of CLIP/OIP, CLIR/OIR, Call Waiting/Communication Waiting etc. is synchronised but that the call 
forwarding status and forwarded-to-number is different from the communication diversion settings and the diverted-to- 
party address. 

If the synchronisation of supplementary services, which use the UE's busy state for invocation, is activated the busy 
state of the UE shall be available in both domains. 

Note: The "user not reachable" or "user not logged in" conditions in the different domains are independent of each 
other. This means, e.g. not being registered in the IMS does not affect the invocation of CFNRc in the CS 
domain. 

Synchronisation of settings means that the most recent changes which have been applied in one domain are propagated 
to the other domain. 

There are certain circumstances under which the synchronisation will fail e.g. when a user inserts a SIP URI as 
diverted-to-party address in the IMS domain which has no Tel URI associated with it. In such a case there is no valid 
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setting for the CS domain for this particular parameter and therefore the CS domain service setting shall remain 
unchanged. The user may receive a notification about the failure of the synchronisation procedure and its cause. 



25 System optimisation for communication with specific 
characteristics 

25.1 Void 

25.2 Numbering Resource Efficiency 

The following optional requirement is intended to provide better numbering resource efficiency for UEs that only 
require packet switched services. 

A network operator shall be able to provide PS only subscriptions with or without assigning an MSISDN. 

Remote triggering shall be supported with or without assigning an MSISDN. 

Remote UE configuration shall be supported without the use of an MSISDN. 

NOTE: Current remote UE configuration solutions (i.e. Device Management and Over-the-Air configuration) are 
mainly based on SMS, which assumes the use of MSISDNs. 

25.3 Network provided destination for uplink data 

The Network Provided Destination for Uplink Data feature is intended for use when all data from a UE is to be directed 
to a network provided destination address. 

For uplink data communication, the network shall be able to direct all uplink PS data traffic to a network 
provided destination address. 

Note: This feature may be used, for example, when all data from an electricity meter is sent to a server maintained 
by the network operator. 

25.4 PS only subscriptions 

The system shall support subscriptions that only allow packet based services and Mobile Terminated SMS. 
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Annex A (normative): 

Description of optional user equipment features 

A.1 Display of called number 

This feature enables the caller to check before call setup whether the selected number is correct. 

A.2 Indication of call progress signals 

Indications shall be given such as tones, recorded messages or visual display based on signalling information returned 
from the PLMN. On data calls, this information may be signalled to the DTE. 

Call progress indicators are described in 3GPP TS 22.001 [4]. 

A.3 Country/PLMN indication 

The country/PLMN indicator shows in which PLMN the UE is currently registered. This indicator is necessary so that 
the user knows when "roaming" is taking place and that the choice of PLMN is correct. Both the country and PLMN 
will be indicated. When more than one visited PLMN is available in a given area such information will be indicated. 

The PLMN name is either; 

Stored in the ME and associated with the MCC+MNC combination received on the broadcast channel; 

NITZ (see 22.042 [17]) (in which case it overrides the name stored in the UE); 

stored in the USIM in text and /or graphic format and associated with the MCC+MNC combination, and 
optionally the LAI, received on the broadcast channel (in which case it overrides the name stored in the UE and 
- if present - the NITZ name). 

It shall be possible to store on the USIM at least 10 PLMN Identifications (MCC+MNC combination and optionally the 
LAI) for which the same PLMN name shall be displayed. 

The PLMN name stored in the USIM has the highest priority, followed by the PLMN name provided by NITZ. The 
PLMN name stored in the ME has the lowest priority. 

If the PLMN name stored in the USIM is not available in text format and the UE is unable to display the graphic 
format, the PLMN name provided by NITZ has the highest priority, the PLMN name stored in the ME has the next 
priority. 

A.4 Service Provider Name indication 

The service provider name is stored in the USIM in text and/or optionally graphic format. It shall be possible to 
associate at least 10 PLMN Identifications (MCC+MNC combination) with the same SP Name. 

When registered on the HPLMN, or one of the PLMN Identifications used for Service Provider Name display: 

(i) The SP Name shall be displayed; 

(ii) Display of the PLMN Name is an operator"s option by setting the appropriate fields in the USIM (i.e. the Service 
Provider name shall be displayed either in parallel to the PLMN Name or instead of the PLMN Name). 

When registered on neither the HPLMN, nor one of the PLMN Identifications used for Service Provider Name display: 

(i) The PLMN name shall be displayed; 

(ii) Display of the SP Name is an operator" s option by setting the appropriate fields in the USIM. 
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If the UE is unable to display the full name of the Service Provider the name is cut from the tail end. The storage of 
Service Provider name and options, and choice of options, shall be under control of the network operator. 

A.4a Core Network Operator Name indication 

It shall be possible for the UE to display the name of the core network operator the user has selected. 

A. 5 Keypad 

A physical means of entering numbers, generally, though not necessarily, in accordance with the layout shown in figure 
A.l. 

See also 3GPP TS 22.030 [6] (Man-Machine Interface). 

Additional keys may provide the means to control the UE (e.g. to initiate and terminate calls). 




Figure A.l 



A. 6 Short message indication and acknowledgement 

This feature allows the delivery of short messages to a UE from a service centre. Such messages are submitted to the 
service centre by a telecommunications network user who can also request information of the status of the message by 
further interrogation of the service centre. The service centre then transmits the message to an active UE user. 

The UE must therefore provide an indication to the user that a message has been received from the service centre and 
must also send an acknowledgement signal to the PLMN to show that this indication has been activated. The PLMN 
then returns this acknowledgement to the service centre. 

The short message service teleservice is described in specification 3GPP TS 22.003 [14]. 

A. 7 Short message overflow indication 

An indication shall be given to the user of the short message service when an incoming message cannot be received due 
to insufficient available memory. 



A.8 



International access function 



Provision is made for a direct, standard method of gaining international access. For this purpose the UE may have a key 
whose primary or secondary function is marked "+". This is signalled over the air interface and would have the effect of 
generating the international access code in the network. It may be used directly when setting up a call, or entered into 
the memory for abbreviated dialling. 
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This feature is of benefit since the international access code varies between CEPT countries, which might cause 
confusion to a user, and prevent the effective use of abbreviated dialling when roaming internationally. Users may still 
place international calls conventionally, using the appropriate international access code. 

A.9 Service Indicator (SI) 

An indication is given to the user that there is adequate signal strength (as far as can be judged from the received signal) 
to allow a call to be made. Additionally the network should be capable of providing, and the UE may display, an 
indication of the serving cells' capabilities e.g. GPRS, HSDPA, HSUPA. 

If indicated by the registered network, the UE in idle mode may display an indication of one of the radio access 
technologies provided to the UE in the network on which the UE is registered with the following priority order; E- 
UTRAN, UTRAN, GERAN. 

Displaying the serving cell's capabilities and the access technology are mutually exclusive. 

A.10 Dual Tone Multi Frequency (DTMF) 

The UE shall be capable of initiating DTMF in accordance with specifications 3GPP TS 22.003 [14]. Optionally, the 
UE may provide a suppress function which allows the user to switch off the DTMF function. 

A. 11 On/Off switch 

The UE may be provided with a means of switching its power supply on and off. Switch-off shall be "soft", so that on 
activation, the UE completes the following housekeeping functions: termination of a current call, detach (where 
applicable) and storing required data in the SIM/USIM before actually switching off. As far as possible, this procedure 
should also apply on power failure (e.g. remote switch-off or low battery). 

A.I 2 Sub-Address 

This feature allows the mobile to append and/or receive a sub-address to a Directory Number, for use in call set-up, and 
in those supplementary services that use a Directory Number. 

A.I 3 Short Message Service Cell Broadcast 

The Short Message Service Cell Broadcast enables the mobile equipment to receive short messages from a message 
handling system. 

The short message service cell broadcast teleservice is described in specification 3GPP TS 22.003 [14] 

A.I 4 Short Message Service Cell Broadcast DRX 

This feature enables a mobile equipment to save on battery utilization, by allowing the mobile equipment to not listen 
during the broadcast of messages the subscriber is not interested in. 

A.I 5 Support of the extended Short message cell broadcast 
channel 

This feature allows a mobile equipment by supporting of the extended Short message cell broadcast channel to enhance 
the capacity of the service. The support of the extended channel has low priority, i.e. the UE can interrupt the reading of 
this channel if idle mode procedures have to be executed. 
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A.1 6 Network Identity and Timezone 



The feature provides the means for serving PLMNs to transfer current identity, universal time and the local timezone to 
mobile equipments, and for the mobile equipments to store and use this information. This enhances roaming by 
permitting accurate indication of PLMN identities that are either newer than the ME or have changed their name since 
the ME was sold. Additionally time and timezone information can be utilized by MEs as desired. 

The network name time and timezone information will normally be transferred from the network to the ME: 

1) Upon registering on the network. 

2) When the UE geographically relocates to a different Local Time Zone. 

3) When the network changes its Local Time Zone, e.g. between summer and winter time. 

4) When the network changes its identity. 

5) At any time during a signalling connection with mobile equipment. 
Further details of this feature are described in 3GPP TS 22.042 [15]. 

A.1 7 Network's indication of alerting in the UE 

This feature provides the means for serving PLMNs to transfer to a UE an indication that may be used by the UE to 
alert the user in a specific manner in the following cases: 

mobile terminating call 

network initiated USSD 

network initiated Mobile Originated (MO) connection, if the ME supports the "network initiated MO connection 
" feature. 

Eight different indications are defined, whether the mobile terminating traffic is a call or USSD or related to the 
network initiated MO connection procedure. These indications are sent by the network and received by the UE: 

Three of these indications are used as levels, reflecting some kind of urgency: level indicates that the UE shall 
not alert the user for USSD and remain silent in the case of call, level 2 shall be considered by the UE as more 
important than level 1 for the purpose of alerting the user. 

The five other indications are used as categories, identifying different types of terminating traffic. The UE shall 
inform the user in a specific manner for each of these five categories. Nevertheless, the possible forms of the 
alert (different ringing tones, displayed text, graphical symbols...) is still up to the mobile manufacturer (some 
forms of alerts can be simultaneously used, e.g. ringing tones and text on the display). 

The management of the feature by the UE requires for the handling of categories that : 

the SIM/USIM stores for each category an informative text (maximum 25 characters per category) describing the 
type of terminating traffic associated with the category. This information could be used by the UE when alerting 
the user (display on the screen). It is necessary for the network operator to be able to change the meaning of each 
category. 

The user has the ability to set up his/her own association between the type of terminating traffic (identified by 
each category) and the different types of alert provided by the UE. To help the user in this choice, the UE uses 
the informative text associated with each category (as stored in the SIM/USIM). The UE should keep this 
association when switched off. 

Default settings should also be defined in the ME for the following cases : 

when the UE receives a call, USSD or a request for a network initiated MO connection with no alerting 
indication. 
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when the UE receives a call, USSD or a request for a network initiated MO connection with a category of 
alerting not defined in the SIM/USIM. 

These default settings should be separated per type of mobile terminated traffic received (call, USSD or request 
for a network initiated MO connection). 

A UE supporting the feature shall act according to the following points in case of mobile terminating traffic : 

when a mobile terminating traffic is received without any indication (level or category), the ME shall act as if it 
was not supporting the feature, i.e. use a default alert (e.g. associated with this type of mobile terminating 
traffic). 

if a level is indicated, the UE shall use an alert enabling the user to differentiate between the three levels. 

if a category is indicated, then : 

if the SIM/USIM used in the UE does not store any information on that feature, the UE shall ignore the 
category received with any mobile terminating traffic and act as if it was not supporting the feature, i.e. use a 
default alert (e.g. associated with this type of mobile terminating traffic). 

if the category is not defined in the SIM/USIM, the UE shall act as if it was not supporting the feature, i.e. 
use a default alert (e.g. associated with this type of mobile terminating traffic). 

if the category is defined in the SIM/USIM, the UE shall use the alert associated with this category. In 
addition, it would be very useful for the user to be notified of the informative text associated with this 
category (e.g on the display). 

Some interactions between this feature and other services related to alerting are described below : 

the call waiting service has priority on this feature, i.e. the call waiting tone will be played and not the alert 
derived by this feature. If possible, two different indications should be given to the user (e.g. the call waiting 
tone and a text on the display indicating call waiting, and in addition a text relative to the type of the new call 
received). 

the presentation of the calling line identity takes priority on this feature, if it is not possible to display this 
information and another information related to this feature. 

In case of interaction between this feature and UE specific features to alert the user (e.g. whole silent mode), the 
user should still be able to differentiate between the different levels or different types of terminating traffic, even 
if the alert itself may be changed. 

A. 18 Network initiated IVIobile Originated (IVIO) connection 

The "Network Initiated Mobile Originated connection" feature allows the network to ask the mobile equipment to 
establish a mobile originated connection. The serving PLMN provides the mobile equipment with the necessary 
information which is used by the mobile equipment to establish the connection. 

Currently only the network initiated mobile originated call feature is specified. It is mandatory for a UE supporting 
CCBS and is used in the case of a CCBS recall. 



A. 19 Abbreviated dialling 



The directory number or part of it is stored in the mobile equipment together with the abbreviated address. After 
retrieval the directory number may appear on the display. 

Abbreviated dialling numbers stored in the UE or USIM may contain wild characters. 

If wild characters are used to indicate missing digits, each wild character shall be replaced for network access or 
supplementary service operation, by a single digit entered at the keypad. The completed directory number is transmitted 
on the radio path. 
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A.20 Barring of Dialled Numbers 



This feature provides a mechanism so that by the use of an electronic lock it is possible to place a bar on calling any 
numbers belonging to a pre-programmed list of numbers in the SIM/USIM. 

Barred Dialling Numbers stored in the /USIM may contain wild characters. 

Under control of PIN2, "Barred Dialling Mode" may be enabled or disabled. The selected mode is stored in the 
SIM/USIM. 

Under PIN2 control, it shall be possible to add, modify or delete a particular "Barred Dialling Number" (BDN) and to 
allocate or modify its associated comparison method(s). This BDN may have the function of an abbreviated dialling 
number / supplementary service control (ADN/SSC), overflow and/or sub-address. 

When BDN is inactive, no special controls are specified, and the barred dialling numbers may be read (though not 
modified or deleted, except under PIN2 control) as if they were normal abbreviated dialling numbers. Access to 
keyboard and normal abbreviated dialling numbers (including sub-address) is also permitted. 

When Barring of Dialled Numbers is active: 

Considering a number dialled by the user, if it exists a BDN for which there is a successful comparison (see 
below) between that BDN and the dialled number, then the ME shall prevent the call attempt to that number. If 
there is no BDN to fulfil those conditions, the call attempt is allowed by the ME. 

With each BDN is associated one (or a combination of) comparison method(s) used between that BDN and the number 
dialled by the user. At least three different comparison methods are possible: 

The comparison is made from the first digit of that BDN, from the first digit of the dialled number and for a 
number of digits corresponding to the length of the BDN. 

The comparison is made from the first digit of that BDN, from any digit of the dialled number and for a number 
of digits corresponding to the length of the BDN. 

The comparison is made backwards from the last digit of that BDN, from the last digit of the dialled number and 
for a number of digits corresponding to the length of the BDN. 

If a BDN stored in the SIM/USIM contains one or more wild characters in any position, each wild character shall 
be replaced by any single digit when the comparison between that BDN and the dialled number is performed. 

If a BDN contains a sub-address, and the same number without any sub-address or with that sub-address is 
dialled, the ME shall prevent the call attempt to that number. 

Numbers specified as "barred" may only be modified under PIN2 control. 

If the ME does not support barring of dialled numbers, the UE with a BDN enabled USIM shall not allow the 
making of calls and the UE with BDN enabled SIM shall not allow the making or receiving of calls. However, 
this feature does not affect the ability to make emergency calls. 

If "Fixed Number Dialling" and "Barring of Dialled Numbers" are simultaneously active, the dialled number shall be 
checked against the two features before the ME allows the call attempt. In that case, a dialled number will only be 
allowed by the ME if it is in the FDN list and if the comparison between that number and any number from the BDN 
list is not successful. 

The UE may support other selective barrings, e.g. applying to individual services (e.g. telephony, data transmission) or 
individual call types (e.g. long distance, international calls). 
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A.21 DTMF control digits separator 



Provision has been made to enter DTMF digits with a telephone number, and upon the called party answering the UE 
shall send the DTMF digits automatically to the network after a delay of 3 seconds (+ 20 %). The digits shall be sent 
according to the procedures and timing specified in 3GPP TS 24.008 [13]. 

The first occurrence of the "DTMF Control Digits Separator" shall be used by the ME to distinguish between the 
addressing digits (i.e. the phone number) and the DTMF digits. Upon subsequent occurrences of the separator, the UE 
shall pause again for 3 seconds (+ 20 %) before sending any further DTMF digits. 

To enable the separator to be stored in the address field of an Abbreviated Dialling Number record in the SIM/USIM, 
the separator shall be coded as defined in 3GPP TS 31.102 [19]. The telephone number shall always precede the DTMF 
digits when stored in the SIM/USIM. 

The way in which the separator is entered and display in the UE, is left to the individual manufacturer's MMI. 

MEs which do not support this feature and encounter this separator in an ADN record of the SIM/USIM will treat the 
character as "corrupt data" and act accordingly. 

A.22 Selection of directory number in messages 

The Short Message Service (SMS), Cell Broadcast Service (CBS), Multimedia Message Service (MMS), Network 
Initiated USSD or Network Response to Mobile Originated USSD message strings may be used to convey a Directory 
Number, which the user may wish to call. 



A.23 Last Numbers Dialled (LND) 



The Last "N" Numbers dialled may be stored in the SIM/USIM and/or the ME. "N" may take the value up to 10 in the 
SIM/USIM. It may be any value in the ME. The method of presentation of these to the user for setting up a call is the 
responsibility of the UE but if these numbers are stored in both the SIM/USIM and the UE, those from the SIM/USIM 
shall take precedence. 



A.24 Service Dialling Numbers 



The Service Dialling Numbers feature allows for the storage of numbers related to services offered by the network 
operator/service provider in the SIM/USIM (e.g. customer care). The user can use these telephone numbers to make 
outgoing calls, but the access for updating of the numbers shall be under the control of the operator. 

NOTE: No MMI is envisaged to be specified for these numbers and it is left to mobile manufacturer 
implementations. 

A specific example of Service Dialling Numbers is the storage of mailbox dialling numbers on the SIM/USIM for 
access to mailboxes associated with Voicemail, Fax, Electronic Mail and Other messages. 



A.25 Fixed number dialling 



This feature provides a mechanism so that by the use of an electronic lock it is possible to place a bar on calling any 
numbers other than those pre-programmed in the SIM/USIM. 

Under control of PIN 2, "Fixed Dialling Mode" may be enabled or disabled. The mode selected is stored in the 
SIM/USIM. 

Fixed Dialling Numbers (FDNs) are stored in the SIM/USIM in the Fixed Dialling Number field. FDN entries are 
composed of a destination address/Supplementary Service Control. Destination addresses may have the format relevant 
to the bearer services/teleservices defined in [21] and [14]. FDN entries may take the function of an Abbreviated 
Dialling Number/Supplementary Service Control (ADN/SSC), Overflow and/or sub-address. Fixed Dialling Numbers 
stored in the SIM/USIM may contain wild card characters. 
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The Fixed Dialling feature is optional, however when Fixed Dialling Mode is enabled, an ME supporting the feature 
shall; 

Prevent the establishment of bearer services/teleservices to destination addresses which are not in FDN entries 
on a per bearer service/teleservice basis. The list of bearer services/teleservices excluded from the FDN check 
shall be stored in the SIM/USIM. Those bearer services/teleservices are characterised by their service code as 
described in [23]. For instance if the SMS teleservices is indicated in this list, SMS can be sent to any 
destination. By default, the ME shall prevent the establishment of any bearer service/teleservice to destination 
addresses which are not in FDN entries. 

Only allow modification, addition or deletion of Fixed Number Dialling entries under control of PIN2. 

Allow the establishment of bearer services/teleservice to destination addresses stored in FDN entries. For SMS, 
the Service Center address and the end-destination address shall be checked. 

Support the reading and substitution of wildcards in any position of an FDN entry, via the ME MMI. 

Allow the user to replace each wildcard of an FDN entry by a single digit, on a per call basis without using 
PIN2. The digit replacing the wildcard may be used for network access or supplementary service operation. 

Only allow Supplementary Service (SS) Control (in Dedicated or Idle mode) if the SS control string is stored as 
an FDN entry. 

Allow the extension of an FDN entry by adding digits to the Fixed Dialling number on a per call basis. 

Allow the emergency numbers (see Section 8.4) to be called, even if it is not an FDN entry. 

Allow normal access to ADN fields (i.e. allow ADN entries to be modified, added or deleted) and the keyboard. 

- Allow use of ADNs subject to the FDN filter. 

When FDN is disabled, an ME supporting FDN shall; 

Allow FDN entries to be read as though they were normal ADN entries. 

Only allow modification, addition or deletion of Fixed Number Dialling entries under control of PIN2. 

Allow normal access to ADN fields and the keyboard. 

If the ME does not support FDN, the UE shall not allow the making of calls when Fixed Dialling is enabled in the 
USIM, and the UE shall not allow the making or receiving of calls when Fixed Dialling is enabled in the SIM. 
However, emergency calls (112 and other user defined emergency numbers) shall still be possible. 

NOTE: Wildcards are stored on the SIM/USIM. The wildcard coding is given in 3GPP TS 31.102 [19]. 



A.26 Message Waiting Indication 



A short message may be used to provide and indication to the user about the status and number of types of messages 
waiting on systems connected to the PLMN. The ME shall present this indication as an icon on the screen, or other 
MMI indication, and store the indication status on the SIM/USIM to allow the status to be retained through power 
off/on, SIM/USIM movement between UEs etc. 

The ME shall be able to accept and acknowledge these message waiting status short messages irrespective of the 
memory available in the SIM/USIM. 

A.27 Requirements for the transfer of eCall IVIinimum Set of Data 
(IVISD) 

With the exception of the following specific requirements, considered necessary for the satisfactory operation of the 
eCall service, all existing TS12 emergency call requirements shall apply. 

An eCall shall consist of a TS12 emergency call supplemented by a minimum set of emergency related data (MSD). 
The MSD e.g. vehicle identity, location information and other parameters, is defined by CEN [46]. 
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An eCall may be initiated automatically, for example due to a vehicle collision, or manually by the vehicle 
occupants; 

An IVS, or other UE designed to support eCall functionality, shall include in the emergency call set-up an 
indication that the present call is either a Manually Initiated eCall (MleC) or an Automatically Initiated eCall 
(AleC). 

The Minimum Set of Data (MSD) sent by the In vehicle System (IVS) to the network shall not exceed 140 bytes; 

The MSD should typically be made available to the PS AP within 4 seconds measured from the time when end to 
end connection with the PSAP is established; 

Should the MSD component not be included in an eCall, or is corrupted or lost for any reason, then this shall not 
affect the associated TS12 emergency call speech functionality. 

A call progress indication shall be provided to the user whilst the MSD transmission is in progress. 

To reduce the time taken to establish an eCall an IVS whilst in eCall only mode, may receive network 
availability information whilst not registered on a PLMN. 

PLMNs should make use of eCall indicators, received in the emergency call set-up, to differentiate eCalls from 
other TS12 emergency calls. 

The MleC and AleC should be used by the serving network to filter and route eCalls to dedicated, eCall 
equipped, PSAPs. 

Where the eCall indicators are not supported by the serving network, the time needed for the PSAP eCall modem 
to differentiate between eCalls and other TS12 calls, before routing the call to an operator, shall not exceed 2 
seconds from when the IVS receives notification that the PSAP has answered the call. 

The PSAP shall be given an indication that the incoming call is an eCall. 

Throughout the duration of the emergency call and following receipt of the MSD by the PSAP 

It shall be possible for the PSAP to send a confirmation to the IVS that the MSD has been acted upon. 

It shall be possible for the PSAP to request the IVS to re-send its most recent MSD. 

It shall be possible for the PSAP to instruct the IVS to terminate the eCall. 

A.28 Requirements for "In Case of Emergency" (ICE) information 

The In Case of Emergency (ICE) information are used to enable first responders, such as paramedics, fire-fighters, and 
police officers, to contact a victim" s emergency contact(s) in order to identify the victim and obtain important medical 
information or other information required during an emergency. 

A UE shall have the capability to store one or more "ICE information" on the UICC. The "ICE information" shall list 
the type of information which is to be configured by the mobile operator as described in the table below. 

Table A.28.1 : "ICE information" description 



ICE information 
type format 



ICE information 
type value 



Description Two formats shall It shall be 



be defined in this 
release: 

1 - Phone number 
format. For the 
phone number 
format it shall be 
possible to store a 
name and a phone 



possible to store 
this information 
in text or graphic 
format. 



ICE information 
value 1 

It shall be 
possible to have at 
least one ICE 
information value 
field. If more than 
one information 
value fields are 
required it shall be 
indicated by the 
ICE information 



ICE information 
value 2 

Present only if 
explicitly 
indicated by the 
ICE information 
type format. 



ICE information 
value n 

Present only if 
explicitly 
indicated by the 
ICE information 
type format. 
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number. 

2- Free format. 

It shall be 
possible for the 
mobile operator 
to provision zero, 
one or several 
instances of a 
given format on 
the UICC. 



type format. 

It shall be 
possible for the 
subscriber to add, 
modify, view, or 
delete any ICE 
information value. 

For the free 
format ICE 
information type 
format, it shall be 
possible to store 
information in 
text or graphic 
format. 

For pre-defined 
ICE information 
type formats the 
ME should adapt 
the input mode to 
the type of the 
ICE information 
value (e.g. 
numerical mode 
for phone number 
input). 



The following table provides an example of ICE information stored on the UICC: 

Table A.28.2: "ICE information" example 



ICE information type 


ICE information type value 


ICE information value 1 


ICE information value 2 


Phone Number 


"Contact in case of 
emergency" 


My Wife 


+3364566 


Phone Number 


"Contact in case of 
emergency" 


Family Smith 


+3364565 


Phone Number 


"Contact in case of 
emergency" 


My Family doctor: Dr. 
Jones 


+33643234 


Free Format 


"Medical Information" 


My blood type is A+, I am 
allergic to etc. 


N/A 


Free Format 


"Home Postal Address" 


15 rue de la Paix, Paris, 
France 


N/A 


Free Format 


"Language" 


French 


N/A 


Free Format 


"Travel Information" 


London, from 3'" July, to 
29* July, 2008 


N/A 



Provision is made for direct and unambiguous read access from the UE to ICE information stored on the UICC. 
The subscriber may choose not to enter any ICE information. 
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The default configuration for this information shall be that they are accessible even when the security features on either 
the UE or UICC have been enabled (e.g. the keypad is locked). It shall be possible for the subscriber to change this 
default setting to prevent accessibility to the ICE information (i.e. a user configurable setting in the UICC indicates 
whether the ICE information on the UICC shall be displayed or not, if the ICE access procedure described in TS 22.030 
[6] is invoked). 

The unlocking of ICE information shall not allow access to other secure information on the UICC or UE. The ICE 
information value should not be accessible to ME or UICC applications. 

The ICE access procedure is described in TS 22.030 [6]. 



£75/ 



3GPP TS 22.1 01 version 1 1 .9.0 Release 1 1 58 ETSI TS 1 22 1 01 V1 1 .9.0 (201 3-07) 



Annex B (informative): 
Additional number use case 



Company X is customer of operator Z and has a subscription for voice and data with 10 SIM cards. The company also 
decides to subscribe to the private numbering plan feature of operator Z. A certain corporate phone number is assigned 
to company X, e.g. +43 676 88888 xx (with xx being the extensions of the users), and they can freely choose the 
extensions for up to 100 SIM cards. 

Initially company X take the existing 10 SIM cards (with the existing MSlSDNs) and integrate them into the private 
numbering plan by assigning the extensions 1 1 to 20 to these cards via a web portal. This is not a permanent 
assignment, the extensions can be changed easily any time, old SlMs can be deleted from the private numbering plan 
and new ones can be integrated whenever necessary. Special privileges or restrictions can be chosen on a per SIM basis 
via the portal and special tariffs apply. 

The CEO of company X calls a customer. The customer's phone displays the corporate number + extension of the CEO 
as CLl. After a while the customer decides to call back the CEO and uses the corporate number + extension as 
MSISDN. Later they also exchange some short messages, again the corporate number + extension of the CEO is used as 
sender's MSISDN. 

For all these calls and short messages operator Z is able to collect charging records containing the corporate number + 
extension. 

The CEO also uses her smart phone to establish PS connections to browse the internet and to access the intranet via the 
operator's gateway. The corporate number + extension is used for authentication and authorisation in the company's 
intranet and its web applications. Charging for PS connections by operator Z is also based on this number. 

In general the users in company X are not aware of their "real" underlying MSISDNs in the system, they only see the 
corporate number + their extension and there is no need for them to know the underlying MSISDN. 
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Annex C (informative): 
Change history 



Change history 


SMG No. 


TDoc. No. 


CR. No. 


Section 
affected 


New 
version 


Subject/Comments 


SMG#22 


302/97 


001 


4.6 (Role 
Model) 


3.1.0 


SMG3 queried the separation of network 
operator into core and access, which, on 
examination, SMGl find unhelpful 


SMG#22 


319/97 
(SMGl 
WPC 

125/97) 


002 




3.1.0 


Editorial Changes: FLMPTS was replaced by 
IMT 2000, 2 new references given, additional 
clarifications. 


SMG#22 


320/97 


003 


8.5, 9.3, 
9.5, 17 


3.1.0 


Changes on Emergency Calls, User 
identification. Multiple profiles and additional 
handover requirements. 


After 

SMG#23 


SMGl 

433U/97 
965/97 


004 




Draft 

3.2.0 


Based on Approved Changes at SMG#22 
Distributed at SMGl in Dresden Nov 3-7, 97 
to be Approved at SMG#24 


SMG#24 


966/97 


005 


Sections 
8,9,11 


3.2.1 


Restructuring of sections 8,9 and 1 1 to gather 
all requirements relating to multiple 
subscriptions into one section and to improve 
the clarity. 


SMG#24 


967/97 


006 


Section 
8.1 


3.2.1 


To improve the accuracy of text on numbering 
principles and minor editorial change to 
section 8.1 


SMG#27 


98-0551 


007 


Section 
4.6 and 

misc. 


3.3.0 


Removal of commercial role model from the 
specification in order to improve clarity 


SMG#27 


98-0552 

(Not 

Approved) 


008 


New Section 

18 

(Not Applied) 


3.3.0 


To include requirements fornetwork selection in service 
principles: NOT APPROVED > NOT APPLIED 


Pre- 

SMG#28 


(SMGl Tdoc 

98-0893) 

99-040 


008 r4 
Rejected 


New 

Section 18 
Applied 


[Draft 
3.4.0] 


Added Network Selection section - Agreed by 
correspondence - Jan 13, 1999 - Prepared with 
CRs applied with revision marks 


SMG#27 


98-0553 


009 


Section 4.3 


3.3.0 


To remove unnecessary reference to IN and B- 
ISDN 


SMG#27 


98-0682 


010 


Section 1 1 


3.3.0 


To improve the clarity of service requirements 
for multiple user profiles 


Pre- 
SMG#28 


(SMG1 
Tdoc 
98-0869) 
99-040 


011 


Sections 1, 
2,3,4,9, 10, 
12, 17 


Draft 3.4.0 


Clean up for UIVITS phase 1 
Agreed at SIVIGI Rome 


Pre- 
SMG#28 


(SMG1 
Tdoc 
98-852) 
99-040 


012 


Sections 

3,8,9,11,14,1 

5 


Draft 3.4.0 


Changes in IC card and terminal service requirements 
Agreed at SMGl Rome 


Pre- 
SMG#28 


(SMG1 
Tdoc 
98-0894) 
99-040 


013r1 


Section 3.2 
&4.3 


Draft 
3.4.0 


Clarification of general requirements for efficient use of 
radio resources 

Agreed bv correspondence - Jan 13, 1999 - Prepared 
with CRs applied with revision marks 


NOTE 








Draft 3.4.0 


SMGl agreed only 
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Change history 


SMG No. 


TDoc. No. 


CR. No. 


Section 
affected 


New 
version 


Subject/Comments 


pre- 
SMG#28 


99-040 


015 
Rejected 


17 


Draft 3.4.0 


According to the outcome of the SMG 1 ad-hoc 
meeting on handover issues it is proposed that inter- 
operator handover is not required for UIVITS phase 
1. (rejected by smg#28) 


SMG#28 


99-305 


008r5 


Revised 
Section 18 


3.4.0 


Networl< Selection presented at SI\/IG#28 in 
2201_008r4 was further revised and Approved at 
SIVIG#28. 


NOTE 








3.4.0 


Removal of Section 12 on UPT with CR 01 1 causes a 
skip section from Section 11 to 13. 



Change history 


TSGSA# 


SA Doc. 


SA1 Doc 


Spec 


CR 


Rev 


Rel 


Cat 


Subject/Comment 


Old 


New 


Wl 


SP-03 


SP-99104 


SI -99202 


22.101 


A016 




R99 


B 


Control of supplementary 
services (GSM 02.04), may use 
MMI procedures specified in 
GSM 02.30 and existing GSM 
MMI related MS features (GSM 
02.07) may also be used. 


3.4.0 






Post- 
SA#3 






22.101 






R99 




Updated Logo, ... 


3.5.0 


3.5.1 




SP-04 


SP-99229 


SI -99387 


22.101 


021 




R99 


B 


MultiNumbering: It will be 
possible for multiple MSISDNs 
to be associated with a single 
subscription. 


3.5.0 


3.6.0 




SP-04 


SP-99226 


SI -99395 


22.101 


020 


7 


R99 


B 


Emergency: To route the call to 
the appropriate emergency 
service if more than one 
emergency number is supported 
in a country. 


3.5.0 


3.6.0 




SP-05 


SP-99439 


SI -99737 


22.101 


025 




R99 


B 


Supportof SATby USIM 


3.6.0 


3.7.0 




SP-05 


SP-99439 


SI -9981 6 


22.101 


024 




R99 


B 


Clarification on the usage on 2G 
SIM and 3G USIM 


3.6.0 


3.7.0 




SP-05 


SP-99435 


SI -99851 


22.101 


022 




R99 


C 


Clarification of Emergency Call 
requirements 


3.6.0 


3.7.0 




SP-06 


SP-99524 


SI -991 031 


22.101 


029 




R99 


B 


Emergency Call 


3.7.0 


3.8.0 




SP-06 


SP-99527 


SI -991 038 


22.101 


028 




R99 


C 


FDN 


3.7.0 


3.8.0 




SP-06 


SP-99519 


SI -991 026 


22.101 


026 




R99 


D 


Mainly editorial update for 
GSM/3GPP use. 


3.7.0 


3.8.0 




SP-07 


SP-000060 


SI -0001 12 


22.101 


030 




R99 


A 


Support of encryption in GPRS 
mobile stations 


3.8.0 


3.9.0 




SP-07 


SP-000070 


SI -0001 37 


22.101 


031 




R99 


F 


Fixed Dialing Number (FDN) 


3.8.0 


3.9.0 




SP-08 


SP-000210 


SI -000271 


22.101 


033 




R99 


D 


Network selection procedures 
removed from section 16, 
reference to 22.01 1 added 


3.9.0 


3.10.0 




SP-08 


SP-000200 


SI -000350 


22.101 


035 




R99 


B 


Emergency Calls and numbers 
used 


3.9.0 


3.10.0 




SP-08 


SP-000201 


SI -000362 


22.101 


038 




R99 


F 


CS multimedia support 


3.9.0 


3.10.0 




SP-08 


SP-000202 


SI -000326 


22.101 


039 




R99 


F 


Clarification for USIM 
Application selection 


3.9.0 


3.10.0 




SP-08 


SP-000210 


SI -000270 


22.101 


034 




ROO 


D 


Network selection procedures 
removed from section 16, 
reference to 22.01 1 added 


3.9.0 


4.0.0 




SP-08 


SP-000200 


SI -000351 


22.101 


036 




ROO 


B 


Emergency Calls and numbers 
used 


3.9.0 


4.0.0 




SP-08 


SP-000213 


SI -000352 


22.101 


037 




ROO 


B 


Emergency Call enhancements 


3.9.0 


4.0.0 




SP-09 


SP-000383 


SI -000603 


22.101 


040 




R4 


B 


Multimedia messaging 


4.0.0 


4.1.0 




SP-09 


SP-000383 


SI -000605 


22.101 


041 




R4 


C 


Service Management 
requirements 


4.0.0 


4.1.0 




SP-09 


SP-000430 


SI -000700 


22.101 


042 


1 


R4 


F 


General corrections and 
clarifications to 22.101 for 
Release 2000 


4.0.0 


4.1.0 




SP-09 


SP-000383 


SI -000598 


22.101 


046 




R4 


D 


Editorial changes to 22.101 for 
Release 2000 


4.0.0 


4.1.0 




SP-09 


SP-000430 


SI -000698 


22.101 


047 


1 


R4 


C 


Numbering Principles 


4.0.0 


4.1.0 




SP-09 


SP-000383 


SI -000620 


22.101 


048 




R4 


C 


Service evolution 


4.0.0 


4.1.0 




SP-09 


SP-000391 


SI -000573 


22.101 


049 




R4 


D 


Emergency Call 


4.0.0 


4.1.0 
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SP-09 


SP-000405 


SI -000649 


22.101 


050 




R4 


B 


Text Conversation 


4.0.0 


4.1.0 




SP-09 


SP-000383 


SI -000625 


22.101 


043 




R5 


F 


Classification of services 


4.0.0 


5.0.0 




SP-09 


SP-000383 


SI -000622 


22.101 


044 




R5 


B 


IP multimedia services 


4.0.0 


5.0.0 




SP-09 


SP-000383 


SI -000621 


22.101 


045 




R5 


B 


IP multimedia session for 


4.0.0 


5.0.0 




SP-09 


SP-000430 


SI -000699 


22.101 


051 




R5 


C 


IM Number portability 


4.0.0 


5.0.0 




SP-09 


SP-000430 


SI -000701 


22.101 


052 




R5 


F 


Introduction of IM CN 


4.0.0 


5.0.0 




SP-09 


SP-000383 


SI -000704 


22.101 


053 




R5 


F 


Subscription 


4.0.0 


5.0.0 




SP-09 


SP-000383 


SI -000705 


22.101 


054 




R5 


F 


Roaming 


4.0.0 


5.0.0 




SP-10 


SP-000533 


SI -000799 


22.101 


059 




Rel-5 


A 


Deleting Encrypted USIM-ME 
interface 


5.0.0 


5.1.0 


TEW 


SP-11 


SP-010053 


SI -01 0072 


22.101 


063 




Rel-5 


A 


Handling of interactions between 
applications requiring the access 
to UE resources 


5.1.0 


5.2.0 


Service 
Clean up 
R99 


SP-11 


SP-010054 


SI -01 0208 


22.101 


065 




Rel-5 


A 


PLMN name indication 


5.1.0 


5.2.0 


TEW 


SP-11 


SP-010055 


SI -01 01 79 


22.101 


067 




Rel-5 


A 


CR to 22.101 on Introduction of 
CPHS features 


5.1.0 


5.2.0 


UICC1- 
CPHS 


SP-11 


SP-010056 


SI -01 0210 


22.101 


069 




Rel-5 


A 


Display of service provider name 
intheUE 


5.1.0 


5.2.0 


TEW 


SP-11 


SP-010057 


SI -01 0250 


22.101 


070 




Rel-5 


C 


CR to 22.101 on Clarifications 
on IMS emergency call support 


5.1.0 


5.2.0 


EMC1-PS 


SP-12 


SP-010262 


SI -01 0505 


22.101 


072 




Rel-5 


A 


Replacement of references to 
23.121 for R4 onwards 


5.2.0 


5.3.0 


TEW 


SP-12 


SP-010258 


SI -01 0574 


22.101 


073 




Rel-5 


C 


Subscription and Provisioning 


5.2.0 


5.3.0 


TEI5 


SP-12 


SP-010255 


SI -01 0577 


22.101 


075 




Rel-5 


A 


Addition of a Streaming 
paragraph 


5.2.0 


5.3.0 


PSTREA 
M 


SP-12 


SP-010263 


SI -01 0351 


22.101 


077 




Rel-5 


A 


CS Multimedia fallback to 
speech 


5.2.0 


5.3.0 


TEW 


SP-12 


SP-010253 


SI -01 0595 


22.101 


080 




Rel-5 


A 


Clarification of PLMN Name 
Indication and Service Provider 
Name Indication feature. 


5.2.0 


5.3.0 


SPANME 


SP-13 


SP-0 10441 


SI -01 0832 


22.101 


084 




Rel-5 


A 


Addition of a statement on 
parameter storage on the 
SIM/USIM. 


5.3.0 


5.4.0 


TEW 


SP-13 


SP-010436 


SI -01 0889 


22.101 


086 


1 


Rel-5 


F 


Definition of Home Environment 


5.3.0 


5.4.0 


VHE1 


SP-15 


SP-020052 


SI -020609 


22.101 


087 




Rel-5 


B 


CR 22.1 01 Rel. 5 B Service 
change and fallback for UDI/RDI 
multimedia calls 


5.4.0 


5.5.0 


SCUDIF 


SP-15 


SP-020049 


SI -020510 


22.101 


088 




Rel-5 


C 


CR to 22. 101 on IMS access 


5.4.0 


5.5.0 


43000 


SP-15 


SP-020051 


SI -02061 3 


22.101 


089 




Rel-5 


C 


CR to 22.101 ononUSIM 
support in Rel-5 GSM only 
terminals 


5.4.0 


5.5.0 


UICC1 


SP-15 


SP-020050 


SI -020658 


22.101 


090 




Rel-5 


C 


CR to 22.101 on Access to IMS 
services using ISIM 

Note: special dispensation was 
given by SA #1 5 to allow some 
leeway on the section 
numbering. 


5.4.0 


5.5.0 


TEI/ISIM 


SP-15 


SP-020045 


SI -020457 


22.101 


092 


- 


Rel-5 


A 


Editorial CR to correct terms and 
references 


5.4.0 


5.5.0 


CORRECT 


SP-15 


SP-020126 




22.101 


093 




Rel-5 


F 


Correction of references to 
obsolete SIP RFC 2543 IETF 
specification 


5.4.0 


5.5.0 


IMS-CCR 


SP-16 


SP-020381 




22.101 


095 


1 


Rel-5 


F 


CR to 22.101 v5.5.0onREL5 
clean up 


5.5.0 


5.6.0 


IMS 


SP-16 


SP-020255 


SI -020848 


22.101 


096 




Rel-6 


D 


CR to 22.101 V5.5.0 on Editorial 
for REL6 


5.5.0 


6.0.0 


IMS 


SP-17 


SP-020557 


SI -021 849 


22.101 


103 




Rel-6 


F 


Clarification of SIM support in 
Rel-6 


6.0.0 


6.1.0 


TEW 


SP-17 


SP-020557 


SI -021 755 


22.101 


104 




Rel-6 


B 


CR to 22.101 Removal of 
implementation details for 
directory number in SMS and 
other services 


6.0.0 


6.1.0 


TEI6 


SP-17 


SP-020557 


SI -021 775 


22.101 


105 




Rel-6 


F 


CR to 22.101 Rel-6 Clean up of 
IMS Rel 6 to re-instate 
requirements 


6.0.0 


6.1.0 


IMS 


SP-18 


SP-020658 


SI -022064 


22.101 


107 




Rel-6 


B 


CR to 22.101 on IMS number 
portability rev of 1 909 


6.1.0 


6.2.0 


IMS 


SP-18 


SP-020658 


SI -0221 19 


22.101 


108 




Rel-6 


B 


CR to 22.101 Rel 6 on 
Emergency calls 


6.1.0 


6.2.0 


EMC1 
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SP-18 


SP-020666 


S1-0???63 


22.101 


109 




Rel-6 


B 


CR to 22.101 onWLAN 
interworking 


6.1.0 


6.2.0 


WLAN 


SP-18 


SP-020651 


SI -022340 


22.101 


113 




Rel-6 


A 


CR to 22.101 on Support of SIM 
and USIM in REL-6 


6.1.0 


6.2.0 


TEI5 


SP-19 


SP-030022 


SI -03021 5 


22.101 


114 




Rel-6 


B 


Simultaneous connection to 
3GPP systems and l-WLANs 


6.2.0 


6.3.0 


WLAN-CR 


SP-19 


SP-030035 


SI -030269 


22.101 


115 


- 


Rel-6 


B 


Requirements for Network 
Sharing in Rel-6 


6.2.0 


6.3.0 


NTShar- 
CR 


SP-19 


SP-030148 


SI -030257 


22.101 


117 


- 


Rel-6 


A 


CR to 22.101 Rel6onSIM 
support 


6.2.0 


6.3.0 


TEI5 


SP-20 


SP-030351 




22.101 


125 


1 


Rel-6 


A 


Alignment of Subscriber 
Identification requirements to 
current implementation 


6.3.0 


6.4.0 


TEI5 


SP-21 


SP-030457 


SI -030911 


22.101 


128 


- 


Rel-6 


A 


Clarification on USIM-based 
access to IMS 


6.4.0 


6.5.0 


IMS 


SP-21 


SP-030492 


SI -031 049 


22.101 


132 




Rel-6 


C 


Cleanup and modifications on 
identification of emergency 
numbers in 22.101 Rel-6 


6.4.0 


6.5.0 


EMC1 


SP-21 


SP-030534 


SI -031 061 


22.101 


134 


1 


Rel-6 


A 


Support of Release 4 SIM in 
Release 6 


6.4.0 


6.5.0 


TEI5 


SP-22 


SP-030700 


SI -031 339 


22.101 


135 




Rel-6 


B 


Automatic Device Detection 


6.5.0 


6.6.0 


TEI 


SP-22 


SP-030700 


SI -031 342 


22.101 


136 




Rel-6 


C 


Correction of Core Network 
emergency call requirements 


6.5.0 


6.6.0 


EMC1 


SP-22 


SP-030687 


SI -031 344 


22.101 


137 


- 


Rel-6 


C 


Clarification of emergency call 
requirements 


6.5.0 


6.6.0 


EMC1 


SP-22 


SP-030790 




22.101 


141 




Rel-6 


A 


Removal of unnecessary 
numbers from the ME default 
emergency number list (Rel-6) 


6.5.0 


6.6.0 


EMC1 


SP-23 


SP-040084 


SI -0401 98 


22.101 


145 




Rel-6 


A 


Alignment to TS 31 .102 on 
FDN/BDN unsupported terminal 
procedure. 


6.6.0 


6.7.0 


TEI 


SP-23 


SP-040091 


SI -04021 5 


22.101 


146 




Rel-6 


B 


Improvements to Circuit 
Switched Video and Voice 
Service procedures 


6.6.0 


6.7.0 


CS-VVS 


SP-23 


SP-040101 


SI -040258 


22.101 


150 




Rel-6 


D 


Extraction of redundant WLAN 
information - now in WLAN 
TS22.234 


6.6.0 


6.7.0 


WLAN 


SP-23 


SP-040101 


SI -040262 


22.101 


151 




Rel-6 


D 


Extraction of redundant WLAN 
related simultaneous connection 
information [ now in WLAN 
TS22.234] 


6.6.0 


6.7.0 


WLAN 


SP-24 


SP-040288 


SI -040427 


22.101 


152 


- 


Rel-6 


F 


Correction of UICC related text. 


6.7.0 


6.8.0 


TEI 


SP-24 


SP-040292 


SI -040537 


22.101 


154 




Rel-6 


F 


Editorial Correction of R5 
reference 


6.7.0 


6.8.0 


IMS2 


SP-24 


SP-040301 


SI -04051 3 


22.101 


153 




Rel-7 


B 


Termination of location privacy 
override for emergency calls 


6.7.0 


7.0.0 


LCS2; 
EMC1 


SP-27 


SP-050058 


SI -0501 61 


22.101 


158 




Rel-7 


A 


Clean-up in Core Network 
Operator Name Indication 
section (22.101) 


7.0.0 


7.1.0 


NTShar 


SP-27 


SP-050059 


SI -050252 


22.101 


160 




Rel-7 


A 


Removal of Reference to TS 
22.121 


7.0.0 


7.1.0 


TEI7 


SP-28 


SP-050216 


SI -05051 9 


22.101 


163 




Rel-7 


A 


Clarification on optionality of 
Service Provider Name 
indication 


7.1.0 


7.2.0 


TEI-6 


SP-28 


SP-050225 


SI -050581 


22.101 


164 




Rel-7 


B 


Voice call continuity 
requirements 


7.1.0 


7.2.0 


VCC 


SP-29 


SP-050522 


SI -050793 


22.101 


0165 


- 


Rel-7 


F 


Correction of emergency 
number example 


7.2.0 


7.3.0 


TEI7 


SP-29 


SP-050522 


SI -050873 


22.101 


0166 




Rel-7 


F 


Requirements on the type of 
emergency 


7.2.0 


7.3.0 


TEI7 


SP-29 


SP-050522 


SI -050796 


22.101 


0167 




Rel-7 


C 


Modification to chapter 4.2 on 
service capabilities 


7.2.0 


7.3.0 


TEI7 


SP-29 


SP-050518 


SI -050896 


22.101 


0168 


- 


Rel-7 


F 


Refinement of general 
description of VCC 


7.2.0 


7.3.0 


VCC 


SP-29 


SP-050518 


SI -050897 


22.101 


0169 


- 


Rel-7 


C 


Charging requirements for voice 
call continuity 


7.2.0 


7.3.0 


VCC 


SP-29 


SP-050518 


SI -050936 


22.101 


0171 


1 


Rel-7 


C 


Clarification of VCC Triggers 


7.2.0 


7.3.0 


VCC 


SP-29 


SP-050522 


SI -050906 


22.101 


0172 


- 


Rel-7 


F 


Clarification on the identification 
of emergency numbers 


7.2.0 


7.3.0 


EMC1 


SP-29 


SP-050522 


SI -050883 


22.101 


0173 




Rel-7 


B 


Provisioning parameters stored 
on USIM 


7.2.0 


7.3.0 


TEI7 


SP-29 


SP-050518 


SI -050934 


22.101 


0174 




Rel-7 


C 


Supplementary Service 
Requirements for VCC 


7.2.0 


7.3.0 


VCC 
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SP-30 


SP-050750 


SI -051 145 


22.101 


0176 




Rel-7 


F 


Correcting reference to OMA 
DM and Client provisioning 
specifications 


7.3.0 


7.4.0 


TEI7 


SP-30 


SP-050746 


SI -051 209 


22.101 


0177 




Rel-7 


F 


Clarification of supplementary 
servces requirements for VCC 


7.3.0 


7.4.0 


VCC 


SP-30 


SP-050746 


SI -051 220 


22.101 


0178 


- 


Rel-7 


F 


Clarification of VCC Triggers 


7.3.0 


7.4.0 


VCC 


SP-30 


SP-050737 


SI -051 236 


22.101 


0179 


- 


Rel-7 


A 


Introduction of Cell capability 
indicator 


7.3.0 


7.4.0 


TEI6 


SP-30 


SP-050805 


- 


22.101 


0180 


1 


Rel-7 


B 


Emergency sip uri to be stored 
InMT 


7.3.0 


7.4.0 


EMC1 


SP-31 


SP-060207 




22.101 


0182 


1 


Rel-8 


F 


Inclusion of AIPN within the 
3GPP service principles 
specification 


7.4.0 


8.0.0 


AIPN 


SP-32 


SP-060448 




22.101 


0186 


1 


Rel-8 


F 


Corrections to align the Rel-8 
and (latest) Rel-7 versions of TS 
22.101 


8.0.0 


8.1.0 


TEI8 


SP-32 


SP-060316 


SI -060561 


22.101 


0187 




Rel-8 


B 


VCC Additional flexibility 


8.0.0 


8.1.0 


VCC 


SP-32 


SP-060315 


SI -060621 


22.101 


0191 


- 


Rel-8 


A 


Clarification of IMS voice service 


8.0.0 


8.1.0 


VCC 


SP-32 


SP-060435 


- 


22.101 


0192 


1 


Rel-8 


B 


QoS Parameters Provisioning 


8.0.0 


8.1.0 


TEI8 


SP-32 


SP-060449 


- 


22.101 


0193 


2 


Rel-8 


B 


High Speed Interface between 
the Terminal and the UICC 


8.0.0 


8.1.0 


TEI8 


SP-32 


SP-060320 


SI -060626 


22.101 


0194 


- 


Rel-8 


F 


Clarification on handling of 
emergency number 


8.0.0 


8.1.0 


TEI-8 


SP-33 


SP-060470 


SI -060939 


22.101 


0197 




Rel-8 


A 


Clarification on Domain 
Selection for MO and MT 
Operations 


8.1.0 


8.2.0 


TEI8 


SP-33 


SP-060468 


SI -060950 


22.101 


0199 




Rel-8 


A 


Emergency calls and ISIM 


8.1.0 


8.2.0 


EMC1 


SP-33 


SP-060472 


SI -060964 


22.101 


0200 




Rel-8 


B 


Requirements for the 
determination of cell capability 
usage - when requested by CN 


8.1.0 


8.2.0 


TEI8 


SP-34 


SP-060777 


SI -061 321 


22.101 


0195 


3 


Rel-8 


C 


Requirements for the addition of 
a data component to TS1 2 
emergency calls and eCall MSD 
(data) transfer requirements 


8.2.0 


8.3.0 


TEMCD 


SP-34 


SP-060773 


SI -061 406 


22.101 


0201 


- 


Rel-8 


B 


Serving Environment / Mobile 
Virtual Network Identification 


8.2.0 


8.3.0 


TEI8 


SP-34 


SP-060765 


SI -061 347 


22.101 


0204 


- 


Rel-8 


A 


Removal of IMS emergency call 
identifier 


8.2.0 


8.3.0 


EMC1 


SP-35 


SP-070130 


SI -0701 90 


22.101 


0205 


1 


Rel-8 


D 


Addition of Evolved 3GPP 
System description and 
corrections to references 


8.3.0 


8.4.0 


SAE-R 


SP-35 


SP-070134 


SI -070299 


22.101 


0207 


1 


Rel-8 


B 


Registration in Densely- 
populated area 


8.3.0 


8.4.0 


RED 


SP-36 


SP-070355 


SI -070673 


22.101 


0211 


1 


Rel-8 


C 


Graphic format of PLMN name 


8.4.0 


8.5.0 


TEI8 


SP-36 


SP-070354 


SI -070802 


22.101 


0214 


1 


Rel-8 


A 


Alignment of SPDI definition 
between TS22. 101 and 
TS31.102 


8.4.0 


8.5.0 


TEI5 


SP-36 


SP-070472 


SI -070790 


22.101 


0215 


2 


Rel-8 


F 


Correction of the backward 
compatibility requirement for the 
HSP interface 


8.4.0 


8.5.0 


TEI-8 


SP-37 


SP-070661 


SI -071 31 4 


22.101 


218 


2 


Rel-8 


B 


ICS Requirements - General 


8.5.0 


8.6.0 


ICS-RA 


SP-37 


SP-070661 


S1-071315 


22.101 


221 


2 


Rel-8 


B 


ICS Requirements - Service 
Consistency 


8.5.0 


8.6.0 


ICS-RA 


SP-37 


SP-070661 


S1-071316 


22.101 


??? 


2 


Rel-8 


B 


ICS Requirements - Service 
Continuity 


8.5.0 


8.6.0 


ICS-RA 


SP-37 


SP-070661 


SI -071 31 7 


22.101 


225 


2 


Rel-8 


B 


ICS Requirements - IMS 
Services 


8.5.0 


8.6.0 


ICS-RA 


SP-37 


SP-070662 


SI -070995 


22.101 


216 


1 


Rel-8 


C 


Clarification on graphic format of 
PLMN name 


8.5.0 


8.6.0 


TEI8 


SP-37 


SP-070676 


- 


22.101 


217 


4 


Rel-8 


B 


Requirements for eCall 


8.5.0 


8.6.0 


EData 


SP-38 


SP-070850 


SI -071 71 2 


22.101 


0232 


1 


Rel-8 


B 


ICS - Clarification of Service 
Continuity 


8.6.0 


8.7.0 


ICSRA 


SP-38 


SP-070850 


SI -071 71 3 


22.101 


0233 


1 


Rel-8 


B 


ICS - Service Continuity 
Requirements 


8.6.0 


8.7.0 


ICSRA 


SP-38 


SP-070850 


SI -071 71 4 


22.101 


0234 


1 


Rel-8 


B 


ICS - Roaming Support 


8.6.0 


8.7.0 


ICSRA 


SP-38 


SP-070850 


SI -071 71 5 


22.101 


0235 


1 


Rel-8 


B 


Clarify UE requirements for ICS 


8.6.0 


8.7.0 


ICS-RA 


SP-38 


SP-070861 


SI -071 932 


22.101 


0229 


2 


Rel-8 


B 


Requirements for Emergency 
Call-Back 


8.6.0 


8.7.0 


TEI8 


SP-38 


SP-070862 


SI -071 927 


22.101 


0241 


2 


Rel-8 


B 


CS IP Interconnection 
requirement 


8.6.0 


8.7.0 


IPINTERC 
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SP-39 


SP-080036 


S1 -080309 


22.101 


0237 


6 


Rel-8 


B 


Requirements for "In Case of 
Emergency" (ICE) information 


8.7.0 


8.8.0 


ICE 


SP-39 


SP-080042 


S1 -080296 


22.101 


0250 


1 


Rel-8 


F 


Update the related contents 
about "Evolved Packet System" 


8.7.0 


8.8.0 


AIPN-SAE 


SP-39 


SP-080041 


S1 -080297 


22.101 


0251 


1 


Rel-8 


F 


CS multimedia calls 


8.7.0 


8.8.0 


TEI8 


SP-39 


SP-080041 


S1 -080298 


22.101 


0252 


1 


Rel-8 


D 


correction of wrong referencing 


8.7.0 


8.8.0 


TEI8 


SP-39 


SP-080032 


S1 -08031 4 


22.101 


0253 


2 


Rel-8 


B 


Requirements for transfer for 
data during emergency calls 


8.7.0 


8.8.0 


EData 


SP-39 


SP-080032 


SI -080266 


22.101 


0254 


1 


Rel-8 


B 


Requirements for the transfer of 
eCall Minimum Set of Data 


8.7.0 


8.8.0 


EData 


SP-39 


SP-080043 


SI -080337 


22.101 


0255 


2 


Rel-8 


B 


RAT indicator 


8.7.0 


8.8.0 


TEI8 


SP-39 


SP-080039 


SI -080287 


22.101 


0256 


1 


Rel-8 


B 


ICS requirement for roaming 


8.7.0 


8.8.0 


ICSRA 


SP-39 


SP-080040 


SI -080237 


22.101 


0262 


1 


Rel-8 


B 


Additional requirements for CS 
IP interconnection 


8.7.0 


8.8.0 


IPINTERC 


SP-39 


SP-080043 


SI -080299 


22.101 


0263 


1 


Rel-8 


B 


Addition of Unique Device 
Identifier to Calling Line 
Identification 


8.7.0 


8.8.0 


TEI8 


SP-39 


SP-080040 


SI -080327 


22.101 


0265 


1 


Rel-8 


B 


Clarification of requirements for 
CS IP interconnection 


8.7.0 


8.8.0 


IPINTERC 


SP-40 


SP-080308 


SI -080746 


22.101 


0267 


3 


Rel-8 


F 


Emergency Call Interaction 


8.8.0 


8.9.0 


EMC1 


SP-40 


SP-080299 


SI -080581 


22.101 


0269 


1 


Rel-8 


C 


eCall call back requirements 
clarification 


8.8.0 


8.9.0 


EDATA 


SP-40 


SP-080298 


SI -080735 


22.101 


0270 


3 


Rel-8 


F 


Common IMS Proposals - 
Requirements for Emergency 
Calls 


8.8.0 


8.9.0 


CIMS 3G 
PP2 


SP-40 


SP-080306 


SI -08071 5 


22.101 


0271 


1 


Rel-8 


F 


Correction of reference for 
PLMN architecture 


8.8.0 


8.9.0 


AIPN-SAE 


SP-40 


SP-080299 


SI -08071 4 


22.101 


0272 


1 


Rel-8 


F 


Corrections to general 
requirements for emergency 
calls 


8.8.0 


8.9.0 


EData 


SP-40 


SP-080308 


SI -080560 


22.101 


0274 


- 


Rel-8 


F 


Clarification of IMS Emergency 
Calls 


8.8.0 


8.9.0 


EMC1 


SP-40 


SP-080299 


SI -080743 


22.101 


0275 


1 


Rel-8 


C 


Reconfigurable eCall only 
terminal access to test and 
reconfiguration services 


8.8.0 


8.9.0 


EDATA 


SP-40 


SP-080302 


SI -080705 


22.101 


0276 


- 


Rel-8 


F 


Correction of ICE requirements 


8.8.0 


8.9.0 


ICE 


SP-40 


SP-08031 1 


SI -080774 


22.101 


0268 


3 


Rel-9 


B 


Requirements for Service 
Alignment and Migration 


8.8.0 


9.0.0 


ETWS-S1 


SP-41 


SP-080498 


SI -0821 92 


22.101 


0282 


1 


Rel-9 


F 


Clarification on IMS services 
supported by ICS 


9.0.0 


9.1.0 


ICSRA 


SP-41 


SP-080643 


- 


22.101 


0280 


2 


Rel-9 


F 


RED optimization of location 
update 


9.0.0 


9.1.0 


RED 


SP-42 


SP-080884 




22.101 


0290 


6 


Rel-9 


A 


ICS Service Continuity 


9.1.0 


9.2.0 


CIMS8 


SP-42 


SP-080779 


SI -08441 5 


22.101 


281 


2 


Rel-9 


B 


User Data Convergence 
Requirements 


9.1.0 


9.2.0 


UDC 


SP-42 


SP-080781 


SI -0841 77 


22.101 


0283 


2 


Rel-9 


F 


VCC for emergency calls 


9.1.0 


9.2.0 


IMS EME 
R GPRS 
EPS 


SP-42 


SP-080784 


SI -084424 


22.101 


0290 


3 


Rel-9 


C 


ICS Service Continuity 


9.1.0 


9.2.0 


TEI9 


SP-42 


SP-080783 


SI -084404 


22.101 


0299 


3 


Rel-9 


B 


UICC applications access to 
IMS 


9.1.0 


9.2.0 


TEI9 


SP-42 


SP-080781 


SI -084096 


22.101 


300 




Rel-9 


F 


Make IMS emergency calls 
available in all access systems 


9.1.0 


9.2.0 


TEI9 


SP-43 


SP-090079 


SI -0901 74 


22.101 


0307 


1 


Rel-9 


A 


Clarification and enhancement 
of ciphering indicator feature 


9.2.0 


9.3.0 


TEI9 


SP-44 


SP-090377 


SI -091 407 


22.101 


0312 


4 


Rel-9 


F 


Domain selection for emergency 
call 


9.3.0 


9.4.0 


IMS EME 
R GPRS 
EPS 


SP-44 


SP-090369 


SI -091 393 


22.101 


0313 


- 


Rel-9 


A 


eCall - PSAP acknowledgement 
to the IVS 


9.3.0 


9.4.0 


Edata 


SP-45 


SP-090475 


SI -093290 


22.101 


0315 


1 


Rel-9 


A 


Minimise delay to emergency 
voice calls 


9.4.0 


9.5.0 


EDATA 


SP-45 


SP-090480 


SI -093282 


22.101 


321 


1 


Rel-9 


F 


Domain selection for emergency 
call 


9.4.0 


9.5.0 


IMS EME 
R GPRS 
EPS 


SP-45 


SP-090483 


SI -093286 


22.101 


0316 


1 


Rel-10 


F 


Add reference to MSD 
specification 


9.4.0 


10.0.0 


EDATA 


SP-45 


SP-090484 


SI -093341 


22.101 


0320 


4 


Rel-10 


B 


Selected IP Traffic Offload 


9.4.0 


10.0.0 


LIPA SIP 
TO 


SP-45 


SP-090483 


SI -093261 


22.101 


322 


1 


Rel-10 


F 


Clarification of emergency call 


9.4.0 


10.0.0 


TEI10 
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back requirements 








SP-46 


SP-090887 


SI -094259 


22.101 


0336 


1 


Rel-10 


A 


Providing eCall indication to the 
PSAP 


10.0.0 


10.1.0 


EDATA 


SP-46 


SP-090836 


SI -094262 


22.101 


0338 




Rel-10 


A 


Remove requirement for 
operator determined eCall call- 
back duration. 


10.0.0 


10.1.0 


EDATA 


SP-46 


SP-090842 


SI -094272 


22.101 


0330 


1 


Rel-10 


A 


User data repository shall be 
possible to be shared among 
different PLMNs that have 
trusted relationships 


10.0.0 


10.1.0 


UDC 


SP-46 


SP-090844 


SI -094499 


22.101 


0327 


2 


Rel-10 


A 


UseofGTT-IPforlMS 
emergency calls (mirror) 


10.0.0 


10.1.0 


TEI9 


SP-46 


SP-090846 


SI -094496 


22.101 


0328 


1 


Rel-10 


B 


ICS Enhancements 


10.0.0 


10.1.0 


TEI10 


SP-46 


SP-090849 


SI -094300 


22.101 


0325 


3 


Rel-10 


B 


Roaming and Mobility aspects 
for Selected IP Traffic Offload 


10.0.0 


10.1.0 


LIPA SIP 
TO 


SP-47 


SP-100187 


SI -100321 


22.101 


0339 


2 


Rel-10 


B 


SIPTO requirements common 
for macro network and H(e)NB 
subsystems 


10.1.0 


10.2.0 


LIPA SIP 
TO 


SP-47 


SP-100188 


SI -100445 


22.101 


0332 


6 


Rel-10 


C 


Clarification to Emergency call 
selection prioritization 


10.1.0 


10.2.0 


TEI10 


SP-47 


SP-100188 


SI -100442 


22.101 


0340 


1 


Rel-10 


C 


Clarification on ICS wrt data 
(CS) and fax 


10.1.0 


10.2.0 


TEI10 


SP-47 


SP-100191 


SI -100431 


22.101 


0343 


2 


Rel-10 


B 


IMS emergency call 
enhancements 


10.1.0 


10.2.0 


lESE 


SP-48 


SP-1 00431 


S1-101060r 


22.101 


0347 


6 


Rel-10 


B 


Addition of Requirement for 
UDC Data Model 


10.2.0 


10.3.0 


TEI10 


SP-48 


SP-1 00401 


S1-101067 


22.101 


0350 




Rel-10 


F 


Correction of reference 


10.2.0 


10.3.0 


lESE 


SP-49 


SP-1 00585 


SI -102403 


22.101 


0353 


2 


Rel-11 


B 


SIPTO mobility/continuity 


10.3.0 


11.0.0 


SIPTO S 
C 


SP-51 


SP-1 10168 


SI -110088 


22.101 


0360 


. 


Rel-11 


F 


Clarification on Service 
Continuity for SIPTO 


11.0.0 


11.1.0 


SIPTO S 
C 


SP-52 


SP-1 10373 


S1-111410 


22.101 


0367 


3 


Rel-11 


B 


IMS emergency call 
requirements for additional 
media types 


11.1.0 


11.2.0 


NOVES 


SP-52 


SP-1 10376 


S1-111209 


22.101 


0369 




Rel-11 


D 


Removing text discrepancy 
between Rel-10 and Rel-11 for 
UDC Data Model 


11.1.0 


11.2.0 


TEI11 


SP-52 


SP-1 1041 8 




22.101 


0372 


2 


Rel-11 


A 


IMS emergency calls 


11.1.0 


11.2.0 


IMS EME 
R GPRS 
EPS 


















Correction of typo on cover page 


11.2.0 


11.2.1 




SP-53 


SP-1 10582 


SI -112392 


22.101 


0373 


1 


Rel-11 


F 


SIPTO in the Mobile Operator 
Network and Local 
Residential/Enterprise Network 


11.2.0 


11.3.0 


TEI11 


SP-53 


SP-1 10576 


S1-112101 


22.101 


0379 




Rel-11 


B 


IMS emergency call support with 
other media handover 
considerations 


11.2.0 


11.3.0 


NOVES 


SP-53 


SP-1 10576 


SI -11 2344 


22.101 


0380 


1 


Rel-11 


B 


Notification of IMS emergency 
call support with other media 


11.2.0 


11.3.0 


NOVES 


SP-53 


SP-1 10576 


SI -11 2350 


22.101 


0385 


3 


Rel-11 


B 


Domain Selection for IMS 
emergency calls with additional 
media types 


11.2.1 


11.3.0 


NOVES 


SP-53 


SP-1 10579 


SI -112385 


22.101 


0374 


1 


Rel-11 


F 


SIPTO Service Continuity 


11.2.0 


11.3.0 


SIPTO S 
C 


SP-53 


SP-1 10579 


SI -112393 


22.101 


0378 


2 


Rel-11 


C 


Clarification on collection of 
traffic and signalling for SIPTO 


11.2.0 


11.3.0 


SIPTO S 
C 


SP-53 


SP-1 10582 


SI -112025 


22.101 


0376 


- 


Rel-11 


F 


Correction of clause numbers 
and editorial corrections 


11.2.1 


11.3.0 


TEI11 


SP-53 


SP-1 10651 


SI -112328 


22.101 


0383 


3 


Rel-11 


F 


Moving "Network provided 
destination for uplink data" 
requirement from 22.368 into 
22.101 


11.2.1 


11.3.0 


SIMTC 


SP-53 


SP-1 10651 


SI -112329 


22.101 


0384 


4 


Rel-11 


F 


Moving PS-Only requirements 
from 22.368 into 22.1 01 


11.2.1 


11.3.0 


SIMTC 


SP-54 


SP-1 10811 


SI -11 3245 


22.101 


0387 


1 


Rel-11 


F 


IMS Multimedia Emergency 
Session support for UEs in 
Limited Service Mode 


11.3.0 


11.4.0 


NOVES 


SP-54 


SP-1 10811 


SI -113249 


22.101 


0388 


2 


Rel-11 


F 


Correction and removal of 
inconsistencies to IMS 
Emergency call when using 
other media 


11.3.0 


11.4.0 


NOVES 


SP-54 


SP-1 10811 


SI -11 3248 


22.101 


0390 


2 


Rel-11 


F 


Indication of supported media 
during an IMS multimedia 
emergency session 


11.3.0 


11.4.0 


NOVES 
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SP-54 


SP-1 10811 


SI -113250 


22.101 


0391 


1 


Rel-11 


F 


Handover of other media to 
networks that do not support 
IMS emergency voice calls 


11.3.0 


11.4.0 


MOVES 


SP-54 


SP-1 10873 


S1-113093r 


22.101 


0392 


2 


Rel-11 


F 


Media allowed on callback from 
PSAP 


11.3.0 


11.4.0 


MOVES 


SP-54 


SP-1 10811 


SI -113094 


22.101 


0393 




Rel-11 


F 


Routing IMS multimedia 
sessions towards the PSAP 


11.3.0 


11.4.0 


MOVES 


SP-54 


SP-1 10813 


SI -113098 


22.101 


0394 


- 


Rel-11 


B 


PS additional number 


11.3.0 


11.4.0 


TEI11 


SP-55 


SP-1 201 03 


SI -120256 


22.101 


0401 




Rel-11 


F 


PS only subscriptions with SMS 
support 


11.4.0 


11.5.0 


SIMTC 


SP-56 


SP-1 20289 


S1-121329 


22.101 


0403 




Rel-11 


F 


Release 1 1 stage 2 alignment 
related to MSISDN-less 


11.5.0 


11.6.0 


SIMTC 


SP-56 


SP-1 20286 


S1-121313 


22.101 


0408 




Rel-11 


A 


Emergency calls from non CSG 
members in CSG cells 


11.5.0 


11.6.0 


EHMB 


SP-56 


SP-1 20288 


S1-121395 


22.101 


0411 




Rel-11 


F 


Clarification of PS additional 
numbers requirement 


11.5.0 


11.6.0 


TEI11 


SP-56 


SP-1 20288 


S1-121391 


22.101 


0413 




Rel-11 


C 


Modification of how ME treats 
emergency call type(s) 


11.5.0 


11.6.0 


TEI11 


SP-57 


SP-1 2051 9 


SI -122462 


22.101 


0422 




Rel-11 


A 


Correction of UE mandatory 
features 


11.6.0 
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